4 ms·

I've tried going the docker environment path before but always hit a roadblock at the actual development stage. VSCode has no idea about your env because it's e

by ryall 7y ago

I've tried going the docker environment path before but always hit a roadblock at the actual development stage. VSCode has no idea about your env because it's effectively non-local. So you lose auto-complete, linting etc. How well does pydocenv handle those kind of issues?

se7entyse7en 7y ago
First of all, thanks for your interest! > VSCode has no idea about your env because it's effectively non-local. This is an issue that I'm aware of, and I actually didn't think about a possible solution yet. Currently, it is in a VERY early stage, but I wanted to share it to get feedback from the community and how much interest the project could raise. The only things that I thought were adding support for example for aliasing of some commands such as running `flake8` will actually call `flake8` inside the container. But it's still very fuzzy in my head.
- pbalau 7y ago
  Not sure how hard this would be, instead of running "flake8 blabla", one can run "docker run bla bla". Or even docker exec bla bla if you have the container already running. And by "you run" I mean vscode does that for you, via an extension.
  - se7entyse7en 7y ago
    That could be an idea, so in practice, you move the responsibility to the editor which I think is actually the correct thing to do. Regarding VSCode specifically I don't know, as I don't use it.
  - haney 7y ago
    This is almost exactly how Pycharm works with testing/auto complete/coverage. It has support to use a a particular interpreter, specific virtual env, or it lets you say “my interpreter is inside this docker container”, which is even allowed to be on a remote host (although I’ve always used docker running locally).
    - lpasselin 7y ago
      I find using pycharm with remote docker painful. If you need unusual docker arguments not included in the pycharm Gui, it sucks. They did a good job but it doesn't seem complete yet.
- ericol 7y ago
  What I've seen around this last days, and seems that is not an easy feature to implement, is providing Python the posibility of live debugging (Something that, for instance, PHP has long ago acquired with xDebug). Im not saying one is better than the other, I'm not going into the discussion "print is better than live" (Which I don't agree with, BTW). I just find it amusing that a language as mature as Python does not have this.
- pard68 7y ago
  Would vim or emacs remote editing options work? Another option is to use an editor that has a server/client model. And for VSCode there is always code-server or a similar project that runs vscode remotely.
henryfjordan 7y ago
Consider running VSCode in docker? https://coder.com/ https://coder.com/
BerislavLopac 7y ago
I'm not quite sure what is really the advantage of this approach. Docker is essentially a process isolation tool, and is well suited for scenarios when you need to isolate a running process, but less when you need to isolate an environment. If you need to isolate a part of the file system, e.g. if your environment only concerns Python files, the standard virtualenv (or venv) is perfectly powerful; if you need to isolate other parts of the system, such as memory, installed binaries and the such, your best bet is vagrant (combined with something like VirtualBox). And both of them work fine with a local IDE. Docker works best for deployment, when you want to set up a running process in a consistent manner, and its closed-box approach works really well in that scenario. But in development you generally want more flexibility.

by ryall 7y ago

se7entyse7en 7y ago

First of all, thanks for your interest! > VSCode has no idea about your env because it's effectively non-local. This is an issue that I'm aware of, and I actually didn't think about a possible solution yet. Currently, it is in a VERY early stage, but I wanted to share it to get feedback from the community and how much interest the project could raise. The only things that I thought were adding support for example for aliasing of some commands such as running `flake8` will actually call `flake8` inside the container. But it's still very fuzzy in my head.

pbalau 7y ago
Not sure how hard this would be, instead of running "flake8 blabla", one can run "docker run bla bla". Or even docker exec bla bla if you have the container already running. And by "you run" I mean vscode does that for you, via an extension.
- se7entyse7en 7y ago
  That could be an idea, so in practice, you move the responsibility to the editor which I think is actually the correct thing to do. Regarding VSCode specifically I don't know, as I don't use it.
- haney 7y ago
  This is almost exactly how Pycharm works with testing/auto complete/coverage. It has support to use a a particular interpreter, specific virtual env, or it lets you say “my interpreter is inside this docker container”, which is even allowed to be on a remote host (although I’ve always used docker running locally).
  - lpasselin 7y ago
    I find using pycharm with remote docker painful. If you need unusual docker arguments not included in the pycharm Gui, it sucks. They did a good job but it doesn't seem complete yet.
ericol 7y ago
What I've seen around this last days, and seems that is not an easy feature to implement, is providing Python the posibility of live debugging (Something that, for instance, PHP has long ago acquired with xDebug). Im not saying one is better than the other, I'm not going into the discussion "print is better than live" (Which I don't agree with, BTW). I just find it amusing that a language as mature as Python does not have this.
pard68 7y ago
Would vim or emacs remote editing options work? Another option is to use an editor that has a server/client model. And for VSCode there is always code-server or a similar project that runs vscode remotely.

henryfjordan 7y ago

Consider running VSCode in docker? https://coder.com/ https://coder.com/

BerislavLopac 7y ago

I'm not quite sure what is really the advantage of this approach. Docker is essentially a process isolation tool, and is well suited for scenarios when you need to isolate a running process, but less when you need to isolate an environment. If you need to isolate a part of the file system, e.g. if your environment only concerns Python files, the standard virtualenv (or venv) is perfectly powerful; if you need to isolate other parts of the system, such as memory, installed binaries and the such, your best bet is vagrant (combined with something like VirtualBox). And both of them work fine with a local IDE. Docker works best for deployment, when you want to set up a running process in a consistent manner, and its closed-box approach works really well in that scenario. But in development you generally want more flexibility.