search

libero / python-project-poc

Proof of concept for Libero python projects going forward
MIT License
0 stars 1 forks source link

expose virtualenv #5

Open de-code opened 5 years ago

de-code commented 5 years ago

I am using Visual Studio Code. So usually I had a consistent virtualenv as a sub directory or link and using a global config it would just pick it up. Or I could configure the path for the project.

The virtualenv is for example used for linting (in addition to running the command).

How do I can I get access to the virtualenv, have you already looked at that?

GiancarloFusiello commented 5 years ago

In PyCharm professional I can use a remote interpreter and point it at a docker service. You might want to do a quick search to see if VSC has the same functionality.

de-code commented 5 years ago

Do you mean it does that for linting or debugging? I think remote debugging should be fine. Just not sure about the linting (haven't found anything yet). It just wants to run pylint (or other tools). A virtualenv might also be more portable for other editors/IDEs.

GiancarloFusiello commented 5 years ago

PyCharm has it's own linters but it gets information from the interpreter such as python version and installed packages to provide linting and autocompletion for: https://www.jetbrains.com/help/pycharm/using-docker-compose-as-a-remote-interpreter.html#docker-compose-remote. I can imagine VS Code has something similar. If not (time to switch?)

You can setup remote debugging but I'm personally not a fan of this as it's laborious. Instead you can insert pdb or ipdb break points. Simply add this where you would like a breakpoint import ipdb; ipdb.set_trace().

I think having a workflow to work with docker containers is necessary in the current climate. As per the proposed guidelines, which editor someone prefers is not a factor.

de-code commented 5 years ago

I think having a workflow to work with docker containers is necessary in the current climate.

I'm not against Docker, I am a proponent of using it where we can and it helps us.

As per the proposed guidelines, which editor someone prefers is not a factor.

I think this should be more like that the project should not be tied to a particular editor. It should still work well with popular editors.

I will look more into VS Code options. Not sure what the requirements are for vim (don't use it myself). But virtualenvs are generally well supported.

de-code commented 5 years ago

Looks like remote interpreters are not supported yet in VS Code.