
Show HN: Python virtual environment, but backed by Docker - se7entyse7en
https://github.com/se7entyse7en/pydockenv
======
ryall
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
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
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.

~~~
haney
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
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.

------
Townley
I didn't follow how this relates to docker. Does running the pydocenv command
modify dependencies stored in the Dockerfile (or a file that pydocenv
references within a "pip install -r ___" command inside the Dockerfile)?

It seems interesting, in that I respect any library (eg pyenv or pipenv) that
tries to solve the issue with pip has compared to npm or cargo, where the
installation of a library isn't coupled to the dependency tracking. I just
can't see from the examples how this is preferable to changing a
requirements.txt file and then rebuilding the docker image

~~~
se7entyse7en
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...](https://github.com/se7entyse7en/pydockenv/blob/master/pydockenv/commands/pydockenv.py#L32).

The activation of the environment corresponds to the start of the container.
Hence inside the container, you don't have (don't need) to have any virtual
env as the isolation is already provided by the container itself.

Every time you install a dependency, this is actually installed inside the
container.

~~~
Spivak
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.

~~~
se7entyse7en
To share your environment with someone else you can run `pydockenv save` (see
here:
[https://github.com/se7entyse7en/pydockenv/blob/master/pydock...](https://github.com/se7entyse7en/pydockenv/blob/master/pydockenv/commands/pydockenv.py#L98)).
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!

------
pritambaral
Personally, I use LXC (via LXD) and Emacs's TRAMP. Tramp is smart enough to
run development tools (like flake8) on the remote, and I get a full OS to play
with, with isolation.

------
rich-tea
What I've wanted for a while now is to be able to run a single jupyter server
but have many kernels running inside different containers. It's possible to
have the kernels in different virtualenvs. I wonder if I could achieve that
with this.

------
rcarmo
I’ve been using and maintaining a set of Python images targeted at doing
builds and packaging for a while now:

[https://github.com/insightfulsystems/alpine-
python](https://github.com/insightfulsystems/alpine-python)

(There is also an Ubuntu variant, but it isn’t fully multiarch yet)

This kind of thing is really useful when you have to build and deploy more
modern/well-known versions of Python than what ships with your distribution,
but I also use them as virtualenv replacements (although the workflow is
different, since you have to derive a new image for each project)

------
ben509
That looks pretty cool! My immediate use for it would be in replacing tox.

It's a lot of downloading, but "docker pull python:3.7.3-alpine3.8" is far
more reliable and simple than building from source. Especially for someone who
just wants to test out a small contribution to a library.

~~~
fock
Seems like someone is indeed compiling: [https://github.com/docker-
library/python/blob/65b5603fdf177c...](https://github.com/docker-
library/python/blob/65b5603fdf177c6d90df6ea6f3bd6e23839c63a4/3.7/alpine3.8/Dockerfile)

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

~~~
ggm
Got a show HN ?

~~~
yorwba
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](https://www.tweag.io/posts/2019-02-28-jupyter-with.html)

~~~
ggm
Awesome! Thanks!

