Show HN: Python virtual environment, but backed by Docker
github.com
github.com
How well does pydocenv handle those kind of issues?
> 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.
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).
They did a good job but it doesn't seem complete yet.
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.
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
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 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.
Seems wild to pass around the actual container rather than an image that spawns your environment.
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!
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)
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.