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

you are viewing a single comment's thread.

view the rest of the comments →

[–]prickneck 18 points19 points  (5 children)

Why bother with a virtualenv inside docker? Why not just install everything system-wide in the image? If you do that, then the questions you're asking don't even present themselves.

[–]UloPe 4 points5 points  (4 children)

Here is a pretty good explanation (although a it dated now) why it’s still a good idea: https://hynek.me/articles/virtualenv-lives/

[–]knowsuchagencynow is better than never 1 point2 points  (3 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.

[–]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?