1

I recently join in current project and find steps in ReadMe like this (and I can't contact with man who create it):

# install pyenv
git clone git://github.com/pyenv/pyenv.git ~/.pyenv
...
pyenv install 3.7.9
pyenv global 3.7.9

# install venv
pip install virtualenv

# create virtual environment
source .venv/bin/activate

# install dependencies
pip install pipenv
pipenv install --dev

...

So my questions are:

  1. what is reason/profit of using virtual environment inside virtual environment?
  2. what is reason/profit of using pyenv or venv if we running application inside python container? Isn't better idea to install all libraries using docker's system pip/python? Docker container is already abstract layer (virtual environment).

pyenv already creating user depending environment that can be easily removed/changed/reseted without influence on system python libraries

In other way environment created with virtualenv still depending on system libraries, so It can't be moved easily between servers.

Maybe here is some benefits or good practices of using venv when service deploying?

Even localstack is using virualenv inside docker. Isn't docker isolation level is not enough?

Update 2022/06/02

According this answer looks like virtualenv may be used to keep size of resulted image smaller.

I checked two patterns:

  • staged build with virtualenv
FROM python:3-alpine as compiler
ENV PYTHONUNBUFFERED 1

WORKDIR /app/

RUN python -m venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"

COPY ./r.txt /app/r.txt
RUN pip install -Ur r.txt

FROM python:3-alpine as runner
WORKDIR /app/
COPY --from=compiler /opt/venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"
CMD ["sleep", "999" ]

and

  • unstaged build without virtualenv
FROM python:3-alpine as runner
WORKDIR /app/
COPY ./r.txt /app/r.txt
RUN python -m venv /opt/venv
RUN pip install -Ur r.txt && pip cache purge

CMD ["sleep", "999" ]

where r.txt is:

django
django-rest-framework
flask
fastapi

Result is:

$ docker images | grep stage
unstaged_python latest 08460a18018c ... 160MB
staged_python   latest dd606b218724 ... 151MB

Conclusion:

venv may be used to save image total size, however size difference is not so big. Also unstaged image may be little bit more cleaned after pip installation to reduce total size. In other words venv usage may reasonable when we have many heavy build operations using compile tools that needed only when build (compile) timing and may be removed when image is ready.

rzlvmp
  • 7,512
  • 5
  • 16
  • 45
  • 1
    Perhaps "old habits" of the one who created the Readme. Perhaps the Readme was made before the organization/user/client used Docker as intensely as right now. As you've said, Docker itself is already a virtual environment. – user2552108 Jan 22 '21 at 02:02
  • @user2552108 yep, I agree, that is may be just a habit without any reasons. But, venv is using in many manuals in the internet, even if that is modern applications that using containers. VM-> Container->(sometimes pyenv)->venv. 3-4 layers of abstraction... And that is usual practice of nowadays... Why? I trying to follow IT trends, but don't feeling/understanding convenience of it. – rzlvmp Jan 22 '21 at 03:00
  • I agree as well. I'm a strong proponent of a virtualenv for every project on my workstations and multi-use servers. But I've been doing Docker for about two years now, and heavy in both Java and Python for about a year, and I've never once created a virtualenv inside a container. Just no need given how specialized a container always is. - now a venv in a venv???...don't get me started with that. That just seems wack! – CryptoFool Mar 05 '21 at 03:51
  • Depending on what you are doing in your build/install and your dependencies, size difference can be big. In my case the unstaged image size was 8.65GB. The staged one's size was 6.13GB. – Allaoua Benchikh May 30 '23 at 13:22

0 Answers0