Enabling extension breaks configured defaultInterpreterPath usage

[MatthewElveyPriceLBS]

I'm maintaining a dev container for a multi-root workspace which builds several virtual envs on creation. Some environments are shared between several projects for efficiency.

For example, the python executable for one environment is at:
workspaces/foo/virtual_envs/bar/bin/python

Several settings files direct the "python.defaultInterpreterPath" setting to this python environment, for their respective projects.

With the python environments extension, using this environment appears to break in two ways:

1. The extension does not detect this environment
2. If I create an environment in a location where the extension does detect it, other projects still completely ignore the defaultInterpreterPath setting.

The intent of the dev container is to involve zero manual configuration by users after loading the container - always use the automatically created and configured environments.

[eleanorjboyd]

Thank you for creating this issue and the info- I will investigate!

[eleanorjboyd]

Hello! So the defaultInterpreterPath setting is a bit complicated as you likely know and explained more here: https://github.com/microsoft/vscode-python/wiki/Setting-descriptions#pythondefaultinterpreterpath. It is quickly overridden by other settings / actions. I think this new extension has the right tools to help you set up your workspace better- we have introduced python "projects" that allow you to connect a folder or file to a interpreter and it automatically updates to the correct interpreter (for all actions) as you move focus to different files/folders.

We are still building docs to explain this feature, here is where you can read about it in the readme. I recorded this video demo-ing what you can do- which after you setup once the setup will be saved for all future loads. Would you be willing to give setting it up like this a try and see if it would work for your use case? This should be an even better improved experience than the existing defaultInterpreterPath setting and could improve the ease of your experience even more

set-project.mov

[freedave]

Seconded. This breaks several of my projects based on pipenv and poetry. I have the python.defaultInterpreterPath set up in my settings.json, which enables the code editor to pick up my libraries and also ties into my terminal shell.

Confirmed that it breaks on multiple laptops and workstations.

Not sure why this extension is being auto-installed on VS code, but it is unwelcome and has caused a lot of lost time.

[eleanorjboyd]

Hi @freedave - sorry to hear this extension is causing problems. We have been testing this extension for over 6 months and know it will provide additional functionality and simplify support for users but it is hitting some bugs as you have found. Would you be willing to try based on my video to get the right setup? Is your issue also in a multiroot scenario?

[freedave]

I dont see any way for this to support pipenv? I just want it my project to use the existing virtual environment that I have set up, regardless of the tool used to create the virtual environment. Before I could just point my settings.json to my virtual environment path -- and I'm done. The video is not clear on what needs to be edited. The interface does not support pipenv -- only conda and venv. Is there an easier way to configure this in settings.json without having to use the interface?

[MatthewElveyPriceLBS]

Hi @eleanorjboyd and thanks for the response. To be specific about my issue, I'm aiming to avoid manual steps. Our dev container has a large number of tools and manual setup for any one tool is simple, but quickly becomes error prone if each tool requires user setup.

Certain manual steps do resolve the issue, in particular, we can simply click the following to select the custom environment for a single project:


Once we select the custom path once, the environment appears in the "Environment managers" view, venv section and we can apply that environment to several projects very easily with this button

Unfortunately these changes don't apply settings I can commit to the repo.

defaultInterpreterPath is definitely complicated and often gets overridden, so I expect the new extension has a lot of advantages. The dev container creates python environments in specific locations, so the downsides are less apparent. Without this extension it's working for users without setting anything manually.

[RaphaelMelanconAtBentley]

Not being able to configure the interpreter/environment to use in settings.json is a real issue for me.
I maintain a repo for a big team, and this is important to ensure people are using the correct environments.

[eleanorjboyd]

Hi everyone! I will put together a more verbose example and share it with yall, just waiting on microsoft/python-environment-tools#235

in the meantime you can always add the setting python.useEnvironmentsExtension: false to go back to the old experience for the time being

[github-actions]

Because we have not heard back with the information we requested, we are closing this issue for now. If you are able to provide the info later on, then we will be happy to re-open this issue to pick up where we left off.

Happy Coding!

[MatthewElveyPriceLBS]

@eleanorjboyd While I understand this issue was tagged "info needed" - it's unclear exactly what information you need beyond what I've already provided. The extension currently has no way of specifying a path for an environment in configuration that can be shared between users and this is quite limiting for automatic environment setup.

[jarrodldavis]

@eleanorjboyd Can this issue be reopened please? The inability to specify the environment for a Python Project created using a dev container is still a problem. As stated before, the manual steps required to change the environment do not persist anywhere that can be committed to a repository. Combined with other issues with this and the main Python extension, it's very difficult to get a one-click setup that doesn't result is strange errors. Dev containers are specifically designed to have a full environment set up from the get-go, so this extension fighting against that goal is strange, if not a bit frustrating.