Live data from Hacker News

Show HN: Python virtual environment, but backed by Docker

github.com

11–20 of 25 posts

Re: Show HN: Python virtual environment, but backed by Docker

#11
post #2

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?

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…

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.

Re: Show HN: Python virtual environment, but backed by Docker

#12
post #10

Earlier quoted context omitted.

When I have some time I could try adding a `How does it work` section. Under the hood the creation of an environment corresponds to the creation of a docker container (that's how it relates to docker). The docker container is built starting from a the official python docker images as you can see here https://github.com/se7entyse7en/pydockenv/blob/master/pydock... . The activation of the environment corresponds to the…

Once I get my environment set up just the way I want in the container how do give it to someone else or make another one? Seems wild to pass around the actual container rather than an image that spawns your environment.

To share your environment with someone else you can run `pydockenv save` (see here: https://github.com/se7entyse7en/pydockenv/blob/master/pydock...). I'm sorry that any example is present in the README so far.

Under the hood, a new docker image is saved from the container corresponding to the currently active environment. A `*.tar.gz` file is created with the image the can be now loaded using `pydockenv load`.

Alternatively, you could push that image to Dockerhub for example and pull it from somewhere else. The problem is that currently there's no mechanism to make it recognize to `pydockenv`, but I'm also planning to add the possibility to create an environment from a user-defined image.

Using `pydockenv save` will ensure that the environment you'll share will be exactly the same. An alternative that I'm also planning to implement is to use a `toml` file that will simply create a new environment from it. Obviously, in your running container, there could be something not captured in the original `toml` file if you, for example, installed something manually inside the container.

But again, it's really in early stage, so all these feedbacks are really welcome!

Re: Show HN: Python virtual environment, but backed by Docker

#13
post #11

Earlier quoted context omitted.

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…

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.

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.

Re: Show HN: Python virtual environment, but backed by Docker

#14
post #11

Earlier quoted context omitted.

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…

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.

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

Re: Show HN: Python virtual environment, but backed by Docker

#16
post #15
post #3

Personally, I use Nix to create my Python virtual environments. That gets the isolation, replicability, and deployability that the author wants, without the heavyweight infrastructure of Docker.

Got a show HN ?

Here's a post by tweag.io about using Nix to manage dependencies of Jupyter notebooks: https://www.tweag.io/posts/2019-02-28-jupyter-with.html

Re: Show HN: Python virtual environment, but backed by Docker

#17
post #2

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?

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…

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.

Re: Show HN: Python virtual environment, but backed by Docker

#19
post #2

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?

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…

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.

Re: Show HN: Python virtual environment, but backed by Docker

#20
post #14
post #11

Earlier quoted context omitted.

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.

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

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.

Post reply on HN