What's the difference between "virtualenv" and "-m venv" in creating Virtual environments(Python)

Question

Sorry if I sound a bit foolish. I'm confused about this what's the difference between the two
virtualenv myvenv
and
-m venv myvenv
The first one works well for me in creating virtual environments while the other does not.
I CD into my development directory and use "virtualenv myvenv" and it creates the virtual environment. But if I use "-m venv myvenv" it just gives errors. Please help me understand

Answer 1

venv is a package shipped directly with python 3. So you don't need to pip install anything.

virtualenv instead is an independent library available at https://virtualenv.pypa.io/en/stable/ and can be install with pip.

They solve the same problem and work in a very similar manner.

If you use python3 I suggest to avoid an "extra" dependancy and just stick with venv

Your error is probably because you use Python2/pip2

Answer 2

I think the virtualenv docs explain this the best:

venv is a subset of virtualenv integrated into the standard library since Python 3.3. The subset meaning that only part of virtualenvs functionality is in venv:

• venv can be slower since it does not have "app-data seed method"
• venv is only upgraded via upgrading the Python version, while virtualenv is updated using pip.
• venv is not extendable
• virtualenv has richer programmatic API (describe virtual environments without creating them). See the venv API here.
• venv cannot automatically discover arbitrarily installed python versions, while virtualenv does. This means, that with venv you have to specify the full path of the python executable, if you want to use some other python version than the first one in the PATH. With virtualenv, you can just give the version number. See python discovery in the virtualenv documentation.

To me the differences are quite subtle and the only practical difference has been that venv is included in the standard library (since 3.3). I have been using python -m venv venv for a long time and have never needed an alternative.