Earlier quoted context omitted.
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
Awesome! Thanks!
Show HN: Python virtual environment, but backed by Docker
21–25 of 25 posts
Re: Show HN: Python virtual environment, but backed by Docker
#22I’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
(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)
Re: Show HN: Python virtual environment, but backed by Docker
#23That 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.
Seems like someone is indeed compiling: https://github.com/docker-library/python/blob/65b5603fdf177c...
Re: Show HN: Python virtual environment, but backed by Docker
#24What 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.
Re: Show HN: Python virtual environment, but backed by Docker
#25I'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?
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.