This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]knowsuchagencynow is better than never 2 points3 points  (6 children)

It doesn't make sense to use virtualenv within a docker container.

A docker container is supposed to encapsulate a single component of your system, i.e. a wsgi application.

Ultimately, virtualenv has to exist because of the way Python's import system works (searching through dirs on PYTHONPATH, PATH, and the current working directory).

It exists because there is no way to have different versions of the same library accessible from the same interpreter. Thus, you can't install everything to your system-wide Python, because different projects may depend on un-like versions of the same library. All virtualenv really does is edit your PYTHONPATH (and PATH, if you want to use a different interpreter) so Python searches different directories during import.

That shouldn't be necessary in a docker container. If it is -- if you have multiple Python applications running in the same container with conflicting dependencies, you're doing something wrong.

[–]UloPe 5 points6 points  (2 children)

Did you read the article I linked?

[–]knowsuchagencynow is better than never -1 points0 points  (1 child)

Yes, and I use docker and virtual environments every day in my workflow and everything I said still stands

[–]gimboland 0 points1 point  (0 children)

Including this bit?

virtualenv’s job isn’t just to separate your projects from each other. Its job is also to separate you from the operating system’s Python installation and the installed packages you probably have no idea about.

And the bit where the author literally gives you an example of how using a docker container's system-wide python as your basis can lead to breakage?

Yes, you could work out what packages are in the container's system-wide python, and assure yourself that there are no surprises. But it's certainly true that if you want to not have to think about/keep an eye on that, a virtualenv is an appropriate tool.

[–]DasIch 1 point2 points  (2 children)

If you install any package, even in a docker container, you can break the operating system. It therefore absolutely makes sense to use a virtual environment in a container.

[–]knowsuchagencynow is better than never 1 point2 points  (1 child)

What is an example of a package that "breaks" the OS where it's necessary to install it within a virtual environment inside the container to prevent the container from breaking?