VS Code Python Buildout Support

Anybody who uses/ has used PyCharm will know how useful the buildout support is. I’ve opened an issue on the Visual Studio Code python extension for buildout support and it would be great to get the plane community to show it’s support for it through a comment or an up-vote on the issue.

@nazrulworld already has a great buildout recipe for adding support, but having it built into VS-Code would make life that little bit easier.

3 Likes

You can partially automate vscode support by adding the recipe to your default buildout in ~/.buildout/default.cfg similar to below

[buildout]
parts = collective.recipe.vscode

[collective.recipe.vscode]
recipe = collective.recipe.vscode
eggs = ${test:eggs} ${instance:eggs}

[test]
eggs=

[instance]
eggs=

Not perfect but gets vscode completing without having to touch your local buildout in most cases.

I've also been testing collective.recipe.vscode occasionally for the last month and it really has some potential.

Issues I've had is that the recipe tries to modify an existing .vscode/settings.json, If the existing json has any 'strict' json errors the recipe will crash on pythons json module trying to deserialize, Took me a while to find sparse ',' at the end of an attribute list.

Also the recipe overrides/bumps into other fields for black and linting you might or might not specify and are already present in your settings.json . I'm not sure if I should like that it overwrites the settings.json.

I'm not sure yet if I want the recipe messing around with all those settings as well: one other useful option it has is to generate an .env file in the .vscode subdirectory which contains the correct PYTHON_PATH for all your buildout eggs. If it could only that and not touch the settings.json that would be nice.

Another thing the recipe does is setting the path to the python interpreter correctly, but I already found a differen solution for that by using the workspaceFolder variable substitution.

{
    "python.pythonPath": "${workspaceFolder}/bin/python2.7",
    "eslint.enable": true,
    "python.formatting.provider": "black",
    "python.formatting.blackPath": "/Users/fred/venv/black/bin/black",
    "python.formatting.blackArgs": ["--line-length","100","-t","py27"],
    "restructuredtext.confPath": ""
    "[python]": {
        "editor.formatOnSave": true,
        "editor.formatOnPaste": false
      },
}

A returning discussion we have at our office on editors and IDE's if you should always install all your add'on utils like black, pylint etc. in every buildout/site project or if you should agree between developers working on a project where your local tools are installed (we also have a tools buildout).

You could also configure 'account' wide settings in the user.json, but I've had little success with the python Interpreter settings, especially when I'm opening both python2 or python3 projects .

Any tips from others?

I am playing with scripts like this one:

When I need it I run ./bin/instance run scripts/vscoder.py > .vscode/settings.json.
It is totally inspired by @nazrulworld excellent recipe but I feel it more manageable for the moment.

@fredvd You are welcome to create issue here https://github.com/nazrulworld/collective.recipe.vscode/issues/new

Also you have free hand to do any modification :writing_hand:

@nazrulworld I certainly will. But I'm a bit reluctant yet to start adding features/idea's to the recipe when I'm still learning about the features of vs code.

Black:
One other vscode /python extension quirk that 'bit' me is that Black is an excellent formatter, but it is no replacement for a linter, you need both activated in a project. Occassionally I'd save a Python file and notice double lines etc. didn't get reformatted. --> black fails silently If you have any syntax error in your python code, or you accidentally forgot to add python27 compatibility flag in a python2.7 project and it would stumble over Print "bla". But I haven't found the output notifications yet for the formatter.

Plone Foundation Code of Conduct