VS Code editor removing pythonPath from workspace/settings.json

fredvd · July 15, 2020, 12:46pm

Only relevant for people using VS code as their IDE for Python projects.

I got a popup after updating VS code this morning that my PythonPath parameter in .vscode/settings.json is deprecated and if VS code should remove it for me.

Apparently this has been a (heated?) discussion for a while, an AB-experiment has been done with 4% of the users and it's a non reversable decision already made.

See:

and also the two related issues linked on the wiki page:

github.com/microsoft/vscode-python

Tweak settings to prevent accidental execution of code from within a workspace

opened 10:36PM - 07 Oct 19 UTC

closed 12:19AM - 28 Jul 21 UTC

brettcannon

debt important needs proposal area-environments

We want to prevent the chance of someone opening a fresh workspace on a reposito…ry to explore the code and then accidentally triggering the execution of code from within that repository. This is possible if you specify certain settings in a certain way, e.g.: - `python.pythonPath` - `python.linting.pylintPath` - `python.formatting.blackPath` - `python.testing.pytestPath` The expected solution to all of this is: - Store a workspace's Python path internally and require the user to select a path/virtual environment manually if it exists within the workspace (#2125) - Make tool paths be user-only, so that installation into an environment still works, but can be overridden only system-wide By requiring a user action to set the Python path to e.g. an virtual environment within the workspace it forces the user to choose to trust that interpreter. And by only running paths to tools as specified at the user level then it doesn't allow a repository to override that location.

github.com/microsoft/vscode-python

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

opened 06:34PM - 10 Jul 18 UTC

closed 12:14AM - 28 Jul 21 UTC

Tiedye

feature-request experimenting area-environments

Be default, a local pipenv environemnt is searched for and if found, is marked a…s 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`.

I haven't read everything yet, but don't understand why they have opted to remove the complete pythonPath parameter. It completely breaks setting up reproducable environments automated.

At Zest we have set up our Plone projects to be as reproducable as possible, so we install a virtualenv in all our project folders for proper isolation of Python modules. So 1 virtualenv per project, inside the project. ignore by .gitignore.

Some other tools/wrappers around venv (virtualenvwrapper) kind of manage virtualenv installed in a central location, presumably under your user/home folder and the wrapper activated the correct venv for your project, but you share venvs between multiple projects. (say Python 3.6, Python 3.8, Python2.7 ).

This is very similar to what nvm (node version manager) is doing for node/javascript. In the npm/yarn world I kind of accept this as the packaging system there has has a strong local/global distinction from the start and an isolated project starts from where package.json is found in the directory tree. But nodejs is not Python.

What I've read in the proposal/docs so far is, because some teams using Python don't isolate their python installs and hence a Python install can be anywhere on their developer machines, setting a pythonPath explictly breaks those setups and detection should be done 'automatically'. Beats me why you have to remove the option alltogether for everybody else.

Until I started setting pythonPath explicitly in my settings.json, VS Code would refuse to pick up my venv/virtualenv inside the workspaceFolder, no matter which instructions I followed from their documentation.

A separate issue but related is that you can still 'set' the default interpreter for your workspace using a shortcut/preference window, but the setting is stored in an internal VS Code config storage only accessible through an API. It remembers for which Workspace you set the interpreter this. Personally I find this very vague and get windows registry deja vu's.

I found out about this separate configuration storage last week when I wanted to disable the MS javascript/typescript extension for my workspace. It is a Plone project with some files that kick the javascript VS code extension to 100% cpu utilization without doing anything. I could only disable the extension using a preferences window and extensions per workspace are also only stored in this isolated registry outside user.json/settings.json.

Because of the feedback coming in from users being impacted by this, a new issue has been opened where people can explain how this change affects their workflow: Details on the A/B experiment removing `python.pythonPath` support · Issue #12313 · microsoft/vscode-python · GitHub

As one user comments at the end of #2125 in the vscode-python repo on github:

@brettcannon, unfortunately this path is a path to closed ecosystem, as it doesn't do much for external tools, but only extensions will benefit.

So how have you set up your workspaces for Plone projects if you us VS code?

fulv · July 15, 2020, 7:53pm

Use vim

djay · July 16, 2020, 4:05am

I created a ticket for it recently. I didn't come up with any solid idea on how to fix it but put some things to research.

Incidentally i added two nice features to the vscode receipe that was just released.

It should now work nicely with pylance using its default settings. Jumping to code definitions etc is all working nicely for me for everything except zope C packages.

You can now also include the vscode recipe is all your buildouts without changing them

Modify/Add ~/.buildout/default.cfg

        [buildout]
        _to_always_include_vscode = ${vscode:recipe}

        [vscode]
        recipe = collective.recipe.vscode
        _to_remove_buildout_warning = ${buildout:_to_always_include_vscode}

sneridagh · November 11, 2021, 5:43pm

Hey Dylan,
I tried this, and it seems that all console logging from buildout are gone now... I am doing something wrong?

djay · November 24, 2021, 6:06am

@sneridagh the method above using ~/.buildout/default.cfg has problems so I no longer recommend it. Maybe try it how I show in VSCode debugging with instance and tests using your existing buildout ?

I'm not sure how it can remove all console logging. I can't really remember why the auto include hack above had problems but I think it had problems in some buildouts where you don't want it.