Handling modules with dots in name

Is your feature request related to a problem? Please describe.
I happen to have a package structure with many sub-packages all versioned.
e.g.
foo
|-bar
|  |-1.0.0
|  |  |-baz.py
|  |-1.0.2
|  |  |-baz.py

Currently using ::: foo.bar.1.0.0.baz is clearly not working
Describe the solution you'd like
What I think would be great is some kind of formatting to include complex paths.
e.g. ::: foo.bar.[1.0.0].baz or ::: foo.bar.{1.0.0}.baz
Describe alternatives you've considered
For now I solved it by renaming the folders 1_0_0 and it works, but in some cases it's not possible.

The path you put after ::: is supposed to be importable. I'm afraid supporting multiple versions of the same package will be hard to support.

It actually is possible to import some module with dots in name using imp or importlib, depending on python version. I know it's kind of odd, but you never know.
Please, keep in mind that my request is a "nice to have" feature. I can bypass this by making a mkdoc for each subpackage version and link them, but you can see that this would be tedious and an implementation for this would be really nice to have.
Maybe another solution could be to use :: instead of ::: to define a package path to import all the dependencies starting from there? Or maybe an handler option to define the path of the package and to import relative to the given path?
Just doing some brainstorming, I don't actually know if that's possible.

It actually is possible to import some module with dots in name using imp or importlib, depending on python version. I know it's kind of odd, but you never know.

That's true, but I don't think you ask your users to import a specific version with importlib? Can you share more about how you package your project and how users make use of it. That would help me understand :slightly_smiling_face:

Please, keep in mind that my request is a "nice to have" feature.

Of course! I'll keep it open anyway.
Thanks for the suggestions. Here's a more detailed state of things:

when injecting docs for a Python object, the Python handler finds the top module and loads it once
it uses the paths specified at the handler level (global-only option) to find that module
since it's a global-only option, there's no way to change the paths for a second load
even if we make the paths option local as well, this needs a big change in the handler and underlying tool, and there's another big issue: you would still get duplicated entries in the objects inventory. For example you'd have both Foo classes for v1.0.0 and v1.0.2, and cross-referencing them would be undeterministic

Usually, different versions of a package are documented under different URLs. Have you seen/tried mike?

We are using rez to manage package versioning. The user will get access to a package by  building a rez call like rez projectName. The call has a setup file for each project that knows what the requirements are and what version of each package to use. If you want to use a specific version you can call rez bar-1.0.2 projectName for example.
I see, now I understand how it works.
Mike might be what I'm actually looking for. In this case would mean that I'll have a site for each sub-package, right? I'd need to use mike to manage versioning and the paths option to define the root module.
foo
|-bar
|  |-1.0.0
|  |-1.0.2
|  |-docs
|  |-site
|-baz
|  |-1.5.3
|  |-2.1.0
|  |-docs
|  |-site

I'd also like to try having a look at custom handlers. I downloaded the python one and I'll dive into it. Any suggestions or links regarding how global/local options work? I couldn't find any technical documentation.

In this case would mean that I'll have a site for each sub-package, right?

Typically, yes. But I think you can document several (different) packages in a single site (just like you can provide several different packages in a single distribution). Then Mike deals with the versioning of docs.

Any suggestions or links regarding how global/local options work? I couldn't find any technical documentation.

That would be https://mkdocstrings.github.io/python/usage/#global-only-options and https://mkdocstrings.github.io/python/usage/#globallocal-options. Let me know if the docs aren't clear or if you were looking for something different.

Thanks, I'm now trying with a different approach. I've seen that most of Griffe's procedures accept the module also as a Path type.
I changed my .md file to include the path, and the handler to send this to Griffe:
# assemblymanager.md
::: photon/ph_diskconnection/1.6.0/ph_diskconnection/managers/usd/assemblymanager.py

# handler.py
def collect(...):
    if "/" in identifier:
        module_path = Path(identifier)
    else:
        module_path = None
    # [...]
    try:
        for pre_loaded_module in final_config.get("preload_modules") or []:
            if pre_loaded_module not in self._modules_collection:
                loader.load_module(pre_loaded_module)
        if module_path:
            loader.load_module(module_path)
        else:
            loader.load_module(module_name)
    # [...]

It looks like It works properly, but I get this error, similar to the one I had in this other issue.
File "RD/kevin.rosso/editoolkit_customHandler/griffe/loader.py", line 131, in load_module
    return self.modules_collection[module_name]  # type: ignore[index]
  File "RD/kevin.rosso/editoolkit_customHandler/griffe/mixins.py", line 30, in __getitem__
    return self.members[parts[0]]  # type: ignore[attr-defined]
KeyError: 'assemblymanager'

Now, I've seen that the top module is correctly recognized as photon/ph_diskconnection/1.6.0/ph_diskconnection/__init__.py but it's obvious that inside my  code there are references to assemblymanager, so why is it a KeyError?
Maybe I can provide you with these files to test, I need confirmation from our pipeline dept.

Now, I've seen that the top module is correctly recognized as photon/ph_diskconnection/1.6.0/ph_diskconnection/__init__.py

That does not look right, it suggests that Griffe thinks it's a namespace package, starting really high in the file tree, at photon, while the actual package really starts at photon/ph_diskconnection/1.6.0/ph_diskconnection.
I'd recommend splitting the identifier in two parts: the relative path where to find the package, and the actual identifier:
::: photon/ph_diskconnection/1.6.0/ph_diskconnection.managers.usd.assemblymanager

path, identifier = identifier.rsplit("/", 1)

Then you feed the path to the loader, as a search path:
loader  = GriffeLoader(..., search_paths=[path])

Thanks to your last suggestion I've been able to make it work!
Here's the code for my custom handler collect() method, leaving it here in case anybody in the future might need it.
I'd maybe suggest to edit the default python handler to being able to handle the paths
    def collect(self, identifier: str, config: Mapping[str, Any]) -> CollectorItem:  # noqa: D102
        # identify module path
        if "/" in identifier:
            module_path, identifier = identifier.rsplit("/", 1)
        elif "\\" in identifier:
            module_path, identifier = identifier.rsplit("\\", 1)
        else:
            module_path = []
        # default python handler stuff
        module_name = identifier.split(".", 1)[0]
        unknown_module = module_name not in self._modules_collection
        if config.get("fallback", False) and unknown_module:
            raise CollectionError("Not loading additional modules during fallback")
        mutable_config = dict(copy.deepcopy(config))
        final_config = ChainMap(mutable_config, self.default_config)
        parser_name = final_config["docstring_style"]
        parser_options = final_config["docstring_options"]
        parser = parser_name and Parser(parser_name)

        if unknown_module:
            loader = GriffeLoader(
                extensions=load_extensions(final_config.get("extensions", [])),
                search_paths=self._paths+[module_path],  # add the module path to the default paths
                docstring_parser=parser,
                docstring_options=parser_options,
                modules_collection=self._modules_collection,
                lines_collection=self._lines_collection,
                allow_inspection=final_config["allow_inspection"],
            )

I still get some collection errors

I can try to help if you open issues with verbose logs,  tracebacks and reproduction examples :slightly_smiling_face:

I'd maybe suggest to edit the default python handler to being able to handle the paths

Maybe in the future yes. Let see how often this gets asked. I'll close this issue for now :slightly_smiling_face:


Dual-publish Definitely Typed packages to github package registry

This PR is the next step in using the github package registry to support Automatic Type Acquisition. It generates two packages side-by-side on disk and calls npm publish on each. But the packages differ only in that the github package.json has a publishConfig entry that specifies the github package registry. This is the same strategy as the dual-publish of types-registry.
I plan to let this run for a few weeks until the package registry hits GA, then switch to publishing to the @types scope on the Types org.
Some notes:

I switched from "npm" | "github" to an enum, including in old code.
I still need to write tests of package removal and actual publishing. I'm not sure how annoying mocking the npm client will be, however. Since I'm on DT next week, watching closely all week after the merge will be worth more than unit tests. The unit tests are really for future changes when I've forgotten how all this works again.
The temporary target is @testtypepublishing, but the eventual target should be @types in order to provide a complete mirror of the @types scope on npm.

The package.json tests read the file system :sweat: so I've got more things to mock.

You got this!


Update readme.md

No, that's the whole point of this module.

Hey @sindresorhus sorry for that. I'm a bit confused. I was under the assumption that this module would take a path in posix format and when on a windows machine convert it.

I'm running a test on different operating systems and I'm expecting a path format to come back with posix.
Uncaught AssertionError: expected { Object (toCwd, toDst) } to deeply equal { Object (toCwd, toDst) }
      + expected - actual

       {
         "toCwd": "foo.txt"
      -  "toDst": "..\\foo.txt"
      +  "toDst": "../foo.txt"
       }

Looking for viable solutions if you have any.

I have no idea why you would assume that. The repo description couldn't be clearer:

Convert Windows backslash paths to slash paths: foo\\bar ➔ foo/bar

I don't know what else to say. It's all in the readme.


Window Close Terminates Application

When I close the application window, the application exits immediately: code after Builder::run() does not run, and managed state is not dropped.
I expect run() should complete and managed state should be dropped.
Platform and Versions
Webview2 - 91.0.864.41

Node.js environment
  Node.js - 14.8.0
  @tauri-apps/cli - 1.0.0-beta.1 (outdated, latest: 1.0.0-beta.2)
  @tauri-apps/api - 1.0.0-beta.1

Global packages
  npm - 6.14.7
  yarn - Not installed

Rust environment
  rustc - 1.51.0
  cargo - 1.51.0

App directory structure
/.vscode
/dist
/node_modules
/src
/src-tauri

App
  tauri.rs - 1.0.0-beta.1
build-type - bundle
CSP - default-src blob: data: filesystem: ws: http: https: 'unsafe-eval' 'unsafe-inline' 'self' img-src:
'self'
distDir - ../dist
devPath - http://localhost:8080/
framework - React
bundler - Webpack```

.run() indeed exits the process; next release will include a run_return API.

.run() indeed exits the process; next release will include a run_return API.

Thanks! Until then is there a good way to drop managed state? I have some read-only state T. To get it to drop now, instead of using State, I use State<RwLock<Option>> and write None before exiting.


Loan issues

Validation for the loan application when there are no members in the group, displaying total loan repid, total interest repaid, total loan balance for the group and displaying group members in the group loan appliction. If the group has pending loans member cannot deleting

Coverage decreased (-0.3%) to 87.058% when pulling 503e485943aab988701b44bde17288e75cbaa805 on swethanaretla:loan_issues into 3820168cf2b8b319ffb2014595848116e18497dd on MicroPyramid:master.


Red and Blue are backwards?

The example application's getScreenshot() method seems to have the red and blue values flip flopped (things that should be red are blue instead and vice-versa.)
This is with iOS 8 on the Simulator and RealVNC Server 5.2.1, using protocol RFB 003.008\n
I haven't yet looked into the problem or tried fixing it, but I'll make a pull request if I end up solving this before anyone else gets to it.

It depends on the default pixel format of the server. You will need to send the pixel format you want to the server.