Replace `virtualenv` with `python3 -m venv` in README.md

[iesahin]

Is there a reason the example's README.md uses virtualenv? It needs to be installed separately. It has more features but for basic use, python3 -m venv can replace it I think.

[shcheklein]

@iesahin one of the reasons usually is that virtualenv also installs wheels automatically. It means for example that DVC can be installed w/o compiling stuff from sources, way faster.

I would also prefer to use python3 -m venv, but I'm not sure yet what to think how to deal with the wheels package. Do additional command? make is part of the requirements? We need to research this a bit.

This decision can affect a lot of places in the docs, btw.

[iesahin]

@shcheklein I believe that's a Debian bug that I accustomed to work around by pip install wheel after activating the environment.

Adding it to requirements.txt doesn't work. Although there are ugly hacks we can't specify the installation order and even if we could, the build phase is earlier so it will look for an already installed wheel.

I'd prefer to mention pip install wheel as a command, rather than specifying a 3rd party package. Creating the virtual environment can also be a link to a common document, telling the reasons and various ways. For example, in Docker I prefer not to use venv, as the container itself is virtual to the root.

There is a new python -m venv option in 3.9. --upgrade-deps will probably fix this. Let me check that.

[iesahin]

Debian Bullseye contains Python 3.9. I installed python3 and python3-venv packages, then tested to create the environment using python -m venv --upgrade-deps env.

It installs from the wheels without error.

[iesahin]

BTW, it looks like the bug causing packages not to be installed from wheels is fixed in Debian stable too.

This is after apt install python3 python3-venv on a clean Debian stable container, with Python 3.7. The problem was that the default setuptools shipped with Python was too old and required update. It looks we can simply use python3 -m venv for virtual environments.

[shcheklein]

It looks we can simply use python3 -m venv

hmm, that's what I get after the clean python3 -m env on Python 3.9.2:

(.env) √ Projects/test-venv % pip freeze
(.env) √ Projects/test-venv % pip list
Package    Version
---------- -------
pip        21.0.1
setuptools 53.0.0

wheel package is not installed.

[iesahin]

In Ubuntu/Debian, at least, python3-venv package depends on python-pip-whl that seems to enable bdist_wheel for pip.

In a new Ubuntu 20.04 container with only  python3 and python3-venv packages installed with apt, after creating the environment and activating, I get:

(hello) root@3d61f038b821:/hello# pip3 list
Package       Version
------------- -------
pip           20.0.2
pkg-resources 0.0.0
setuptools    44.0.0

Installation of, e.g., pillow is using just the.whl package:

(hello) root@3d61f038b821:/hello# pip3 install pillow
Collecting pillow
  Downloading Pillow-8.2.0-cp38-cp38-manylinux2014_aarch64.whl (2.8 MB)
     |████████████████████████████████| 2.8 MB 1.4 MB/s
Installing collected packages: pillow
Successfully installed pillow-8.2.0

wheel is not installed but that functionality seems to be present after installing python-pip-whl.

@shcheklein

[shcheklein]

@iesahin should we update this and/or close?

[iesahin]

I couldn't decide on this. Maybe using -m venv in the new docs and waiting for the issues is a better strategy?

@shcheklein

[shcheklein]

yeah, my only concern that issue can be "build is too slow" - it'll take time for us to realize this. I'm fine to wait for that though. The only thing I would recommend is to try to build/install DVC and other repos on a clean machine (no wheel cache, etc).

[shcheklein]

Closing for now.