vscode-python: Change venvFolders to no longer be anchored to the user's home directory

I ran across this issue because I have the following use case:

• rootWorkspaceDir (not relative to homeDir)
  • subProject1Dir
    • venvDIr
  • subProject2Dir
    • venvDIr

Making venvFolders not relative to the user’s home dir would allow me to specify each subproject once and easily switch between the corresponding environments as I switch between projects. The current workaround is to update venvPath or pythonPath each time I switch.

What’s the current status of this? venvFolders and venvPath still exist, and are inconsistently documented:

• https://code.visualstudio.com/docs/python/environments#_where-the-extension-looks-for-environments only mentions venvPath
• https://code.visualstudio.com/docs/python/settings-reference#_general-python-settings only mentions venvFolders (but not the fact that it’s relative to your homedir)

I thought the original plan, to make venvPaths an array of entries like venvPath works today, and to get rid of venvFolders, made sense. It’s the least surprising (can be relative to ${workspaceFolder} or not), and supporting multiple entries makes it work with many tools, other filesystems mounted outside one’s home directory or project root, etc. It could be overridden in .code-workspace or settings.json files for projects to provide good defaults in source.

Did this ticket just get forgotten about? It would very much improve my company’s use cases to see this happen.

1. Make pyenv and direnv support not rely on venvFolders
2. Create venvPaths which is an array of directories which contain virtual environments
3. Deprecate venvFolders and venvPath
4. Make sure environments list gets updated when settings change

Did this ticket just get forgotten about?

Honestly, yes. We have been very focused in the interim time this issue was opened by completely rewriting the environment discovery code, iterating on the quick pick menu, and then getting an extension API for other extensions to use. Now that’s all finished, we can look to try and pick this up in 2023.

Any rule of thumb of how I should be using one or the other and both?

Since we now know how to patch a user’s setting we can actually drop venvPath and then change a user’s preexisting settings to append ~/ to entries (or something along those lines).