VS Code editor removing pythonPath from workspace/settings.json

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.


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

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: https://github.com/microsoft/vscode-python/issues/12313

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?

1 Like

Use vim :crazy_face:

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

        _to_always_include_vscode = ${vscode:recipe}

        recipe = collective.recipe.vscode
        _to_remove_buildout_warning = ${buildout:_to_always_include_vscode}
1 Like

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

@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.