Execution environments

[travisdowns]

Is there any intuition for the limited set of properties set by "execution environments" (hereafter: ee)?

That is you can only change the python version, path and extra paths, but I think one would also perhaps like to specify other options on a per-ee basis too like stubPath, default strictness level etc.

As I see it, the main use of ee is to support the case where several python "projects" are embedded in a larger root directory (think monorepo). In that case, it's not obvious that the projects want to share any setting, but as I understand it for pyrightsettings.json to be picked up in applications which integrate it like vscode, it needs to be in the root directory of the "workspace": so all python projects under the root need to share a single config: ee seems to offer a way to customize each project but the set of overrides is very limited so I wonder if I'm thinking of it wrong somehow.

have done a search for similar discussions*

I clicked this to post but I haven't.

[erictraut]

In retrospect, I wish I hadn't added support for execution environments to pyright. It was a very early feature, and it hasn't aged well. I don't plan to extend the feature. If anything, it may be deprecated over time.

The problem is that there is no true separation between execution environments. If a module is shared between them (e.g. a file that is imported by files located in two different execution environments), that common module is analyzed only once. If the shared module contains type information that is conditioned on the python version or platform, its evaluated types depend on which importing module happens to be analyzed first. The type information in the shared module is then cached in memory, and the second importing module is stuck with the incorrect type information.

Fixing this limitation would require a complete overhaul of the way that execution environments are implemented, and that's unlikely to happen. The language server variant of pyright already supports multi-root workspaces (a feature of the language server protocol), and multi-root workspaces provide true separation between workspace roots. So if you're using the language server variant of pyright, that's a preferable solution.

If you're not using the language server variant of pyright and are instead using the CLI, you can get the same effect by simply running the CLI multiple times via a script. Each run can specify a different python version, platform, stub path, type checking rules, etc. This gives you maximal flexibility in determining how you want different subsets of your code base to be type checked.

[alita-moore]

please don't deprecate it, it would make monorepos impossible

[travisdowns]

I really appreciate this response erictraut! The background helps understand that execution environments are basically a vestigial feature, won't be extended and I wouldn't rely on them heavily.

So if you're using the language server variant of pyright, that's a preferable solution.

If you're not using the language server variant of pyright and are instead using the CLI, you can get the same effect by simply running the CLI multiple times via a script. Each run can specify a different python version, platform, stub path, type checking rules, etc. This gives you maximal flexibility in determining how you want different subsets of your code base to be type checked.

The answer is we are using both. I'm writing a pyright integration for our CI which will enforce the type checking rules, so that's a CLI use and developers are typically using vscode or vim LSP integrations to type check their code while editing. So I wanted both scenarios to use the same configuration. Multi-root seems like it would well, however the existing pattern for development is to open the root of the monorepo and not to multi-root the projects contained within. In any case, based on bugs I've seen with nested workspaces I understand that mutli-root workspaces should be disjoint: I.e., open dir A and dir B as different roots where neither is an ancestor of the other. In our scenario however, everyone will keep opening the monorepo root and if they were to additionally open new roots for python projects under there they would be nested under the root which I guess causes problems like double analysis, etc.

Thanks again for your response!