Select a Python Interpreter without modifying the workspace's settings.json

[Tiedye]

Be default, a local pipenv environemnt is searched for and if found, is marked as the python interpreter. But it also then adds a line to settings.json indicating the path for the virtual environment which can cause issues for configs shared among a team. The python.pythonPath variable will not be constant for each user working on the repo (eg "python.pythonPath": "/home/daniel/.local/share/virtualenvs/ontariofresh_backend-NQNAEc6t/bin/python", note my home directory in the path) and thus prevents the settings.json file from being committed to the remote repository.

Ideally, it would behave just as it does now, but just implicitly sets the python interpreter as the one found without explicitly writing it out to settings.json.

Environment data

• VS Code version: 1.25.0
• Extension version (available under the Extensions sidebar): 2018.6.0
• OS and version: ubuntu 18.04
• Python version (& distribution if applicable, e.g. Anaconda): 2.7.15
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): pipenv

Actual behavior

The installed pipenv virtual environment is found and selected as the python interpreter and the path to that environment is added to settings.json.

Expected behavior

The installed pipenv virtual environment is found and selected as the python interpreter and the path to that environment is not added to settings.json.

[brettcannon]

[I edited your ✉️ ⬆️ to come off as more 😃 and less 😠 ]

Yes, VS Code's lack of "workspace-personal" on top of a "workspace-global" config can be a problem in this situation.

[Tiedye]

Ha sorry, didn't realize I was coming off as 😠

[brettcannon]

@Tiedye No problem! It was basically phrasing as "this is bad!" can be off-putting because it comes off as a demand instead of a request.

[brettcannon]

@Tiedye a work-around for this is to set PIPENV_VENV_IN_PROJECT and the extension will automatically pick up the .venv directory that gets created. And you can set python.pythonPath to ${workspaceFolder}/.venv to be consistent within your project without any hard-coded, absolute paths.

[Tiedye]

Awesome! That works. Should the issue be left open? Or is this more of a vs-code issue at this point.

[brettcannon]

We can leave this issue open to consider coming up with a solution that negates the need to force you to set an environment variable (at worst we could document this for users).

As for getting personal workspace settings, I believe there is a VS Code issue on this topic so if you can find it and upvote it then that might help get it implemented.

[Tiedye]

microsoft/vscode#15909 for reference

[mungojam]

set PIPENV_VENV_IN_PROJECT

I'm thinking of using this workaround too as I can easily roll out environment variables to all our devs. The unfortunate thing about it is that the .venv isn't in the default .gitignore in our version of GitHub Enterprise so we'll need to remember to add it to every repo. It is in the public github.com version

[thernstig]

@brettcannon Is that the only workaround or could you opt not to update .vscode/settings.json in some way and still use the Pipenv virtualenv's pythonPath?

It's great that VS code is working on a general fix in microsoft/vscode#15909 though. I am wondering however if it is customary for extensions to automatically update a workspace's settings? As settings.json is aimed to be shared amongst team members of a project it becomes problematic if it is updated with individual settings, such as in this issue.

[brettcannon]

@thernstig I don't know if there's any customary practice that has been established by the VS Code extension community. For us we do it because there's a visible startup cost in searching for a person's environment, so writing it out short circuits that search.