Behavior of python-env.workspaceSearchPaths

[akpircher]

I initially wanted to make an issue titled Setting python-env.workspaceSearchPaths "globally" is ignored, but while looking to see if there was already an issue for this, I found the PR and that behavior looks intentional #863 (comment).

So there are really two parts to this issue: one for the current behavior, and a second for the extension to respect a "globally" (profile/user/application) set python-env.workspaceSearchPaths value.

Current behavior

1. I think the documentation for the setting should declare that it is a workspace-level setting only. Setting it globally, only for it to be ignored without that being documented makes it look like there is a bug.
2. It doesn't look like the setting interpolates vscode variables. If I set the value to ${workspaceFolder}/local/path, the venv manager does not find anything. However it does if I set the value to local/path.

Desired behavior

One of the long-running issues VS Code has had with managing Python environments in the past was that you could not specify a virtual environment path without modifying your workspace settings.json, which was annoying to deal with if you wanted to commit the settings.json to share other settings.

This resulted in teams either not sharing their .vscode/settings.json, or forcing everyone in the team to put their virtual environment in the same location for VS Code to correctly find the virtual environment.

When Python support was refactored out into it's own extension¹, this was basically fixed. Searching for virtual environments wasn't perfect, but we no longer had to put our local virtual environment setup in the workspace settings.

Providing a python-env.workspaceSearchPaths setting that is only listened to when set for the workspace feels like a regression. IIRC, one idea that was thrown around in the issue discussion for the Python virtual environment setting was having a separate json file for local python settings, like the launch.json and extensions.json, but was dismissed because it did not match the design. It was ultimately a setting.

But if python-env.workspaceSearchPaths really is a setting that shouldn't be managed globally, then maybe this extension should consider managing workspace-level settings in a separate file, or maybe it should also listen to python.venvFolders/python.venvPath. Even though this setting is a list, creating a setting where everybody adds an entry for where they store local virtual environments is potentially cumbersome or becomes a setting that exists for one person and nobody else.

---

Sorry for the long description, or potentially repeating information you're already familiar with. I think the setting is drastic improvement over python.venvFolders/python.venvPath.

Footnotes

1. (Or maybe when a major refactor happened in the Python extension, I don't remember) ↩

[eleanorjboyd]

Hi! Thanks for the feedback and we are currently developing this area and do plan to make improvements to what exists right now. First, we have a setting python-env.globalSearchPath - that is what I think you want. Things we are planning on doing:

1. fixing documentation once this area stabilizes
2. allowing regex for python-env.workspaceSearchPath, this will make it different than python-env.globalSearchPath and will give you more options

Things we need to do (after you pointed them out):
3. support ${workspaceFolder}/local/path

Right now python.venvFolders/python.venvPath both also still work but this will go away in favor of these two new ones. With this explanation does it feel like the new experience is useful / not a regression? What else do you think is missing?

[akpircher]

@eleanorjboyd sorry for the very delayed response. My understanding is that python-env.globalSearchPath is for finding virtual environments stored outside of the worktree.

Is the intent of python-env.globalSearchPath to include worktree paths as well? So it should include a definition for ${workspaceFolder}/.local/direnv or ${workspaceFolder}/.local/venvs?

But I'm still not entirely convinced that the scenario where sharing python-env.workspaceSearchPaths is common enough to make it a local-only setting (assuming a team decides to share .vscode/settings.json). Where a developer chooses to keep virtual environments, locally or globally, is inherently a personal preference.

The primary use case I can think of to share this setting with others is in a repository containing code that sets up an environment for a team new to Python, less experienced in Python, or where they need to use the code without caring how to develop it, and for some reason publishing the repository as a python package is less feasible or not ideal.

I don't know how common that scenario is, I'm certain it exists, but I'm not sure that's your primary target demographic.

[akpircher]

If it's okay to make a suggestion about allowing regular expressions, do you mean proper regular expressions or glob matching? Both scenarios seem kind of risky and like the extension may accidentally cause VSCode to hang or crash in very large directories.

(I have accidentally done this when overriding Pyright's exclude configuration without including the the defaults)