Question about Project Settings and pyrightconfig.json

[munkybutt]

Hi!

Is it possible to use project specific settings in conjunction with pyrightconfig.json settings?
My setup is a bit convoluted:
I have a sub-project within the folder structure of my main project.
The sub-project folder structure starts from the same location as the main project as I have dependencies through out the main project that I want to be able to work with in the sub-project.
This means the pyrightconfig.json in the root of the main project defines the pyright settings for the sub-project.
To work around this, I am trying to add extraPaths to the project settings but the imports in sub-project are not being resolved unless I add them to the main project's pyrightconfig.json.
My structure is like so:

• Root
  • pyrightconfig.json
  • MainProjectRoot
    • SubProjectRoot
      • Project Settings

Main Project pyrightconfig.json:

{
    "pythonPlatform": "Windows",
    "pythonVersion": "3.7",
    "extraPaths": [
        "<MainProjectRoot>",
        "libs/_all_versions/Lib/site-packages",
        "libs/37/Lib/site-packages"
    ],
    "ignore": ["./*.pyi"],
    "stubPath": "./../../../.projects/.stubs",
    "executionEnvironments": [
        {
            "root": "<MainProjectRoot>"
        },
        {
            "root": "<MainProjectRoot>/<SubProjectRoot>",
            "pythonPlatform": "Windows",
            "pythonVersion": "3.9"
        }
    ]
}

And my project settings are:

{
"settings": {
      "LSP": {
         "LSP-pyright": {
            "settings": {
                "python.analysis.extraPaths": [
                   "<absolutePathToSubProjectDependencyDirectory>"
                ]
            }
         }
      }
   }
}

Any advice would be appreciated!

[rchl]

I'm not sure if you are confused about this or not but the location of the project file (which I believe you are calling "project settings" which is not entirely precise) is not really relevant. The settings in project file apply to folders defined by the folders array in that file. The location of that file doesn't matter.

That said, I don't think I fully understand your issue. Maybe it would be more clear to me if you would specify what the folders in the project file are set to.

[silverwind]

I notice a similar issue: When the root folder in Sublime does not contain the pyrightconfig.json, LSP-pyright does not find it, even thought it exists in a parent folder of the file being analyzed.

It could be solved if LSP-pyright would just look for the closest pyrightconfig.json starting with the file being analyzed, e.g. /folder1/folder2/file.py would try /folder1/folder2/pyrightconfig.json, /folder1/pyrightconfig.json and /pyrightconfig.json and use the first one that exists.

Above is how many other linters like eslint work, but I'm not sure it matches the behaviour of pylint cli as that seems to be tailored specifically to VSCode's workspace feature.

[jfcherng]

@silverwind yours sounds more like a job of pyright rather than lsp-pyright.

[rchl]

Many servers choose to limit lookup of configuration files to the root folder of the opened project. And there are often good reasons for that. For example check microsoft/pyright#1756

[silverwind]

Yes, non-root config files are ultimately something for pyright to support, if they can be persuaded to do so, but I doubt it.

Some tools like eslint do it by default, many others like pyright or pylint don't.

Per-directory config files are a very useful pattern for many reasons, it's a shame some tools decide to not support it.

[rchl]

This can work if configuration options apply only to the currently checked file. If some of the options are global in nature and apply to the whole project then it becomes undefined which configuration applies when. Or you end up with options that don't do anything and it's not obvious. It's just hard to support and in many cases doesn't make sense, depending on the architecture of the server.

[silverwind]

If some of the options are global in nature and apply to the whole project then it becomes undefined which configuration applies when

In case of multiple files, the nearest (e.g. more specific) config file could outweight the others. Of course, care needs to be taken in how the options are merged together (e.g. in some cases it makes sense to combine, in others to replace), but I think this is a solveable problem in general.

For my use case specifically, it's not even multiple config files. I have projects in a subfolder whose parent folder is added to the Sublime's sidebar. I don't use workspaces or any of Sublime's config files at all as I want to be editor-agnostic. I'd like either LSP-pyright or pyright to find the closest config file. Currently this is only possible if I drag each individual project folder into ST, but that is cumbersome if you have hundrets of projects you switch between often.

FWIW, SublimeLinter looks to have implemented this recently for their python linters.

[munkybutt]

My situation is a bit more unique I think, where I have a project within a project.
The sub-project can be a standalone package or a sub-package of the main project. It also has dependencies on packages in the main project.
So when I open the main project I want pyright to treat the sub-project as a package of the main project, which it does.
But when I open the sub-project I want it to open as if it is a top level project, but as they both share a root path the sub-project opens with the pyright config of the main project. I wanted to override this behaviour in the sub-projects sublime settings but it appears to have no effect.
Sorry - quite hard to explain 😞

[munkybutt]

Oh and nested pyrightconfigs would be great if supported - but obviously that is for pyright to sort not you guys

[rchl]

Since this is something that can't be addressed by this package, there is no reason to keep it open.

As for your setup, I feel that it's unnecessarily complicated. You could probably have those two projects completely separate and then add both as individual folders to the sidebar / project. And then to make Python resolve paths correctly, you could extend python.analysis.extraPaths in either of those or in project settings.