98

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.

Melebius
  • 6,183
  • 4
  • 39
  • 52
Prince Kwekowe
  • 993
  • 1
  • 6
  • 6
  • 6
    You would need to use `python -m venv myvenv` for that to work..., where `python -m` calls the `venv` module as a script and passes `myvenv` as an argument to that script. – juanpa.arrivillaga May 20 '17 at 23:51
  • This question is misleading because it is presented as if it were about the difference between two commands, but OP appears to have been **actually asking** why the second version, `-m venv myvenv`, **verbatim**, doesn't work at all. The reason it doesn't work at all is because it is **not a valid command**; it should say `python -m venv myvenv` instead. – Karl Knechtel Aug 27 '23 at 17:59
  • "But if I use -m venv myvenv, it just gives errors." - this is a **textbook** example of why questions that lack debugging details should be closed immediately. "What errors?" would have immediately cleared up the confusion. Instead, we get a poorly-asked version of a "canonical" (that is still not great; "what's the difference" questions are normally two smaller questions in a trenchcoat). – Karl Knechtel Aug 27 '23 at 18:00
  • ... Actually, even overlooking that, it wouldn't be a canonical for the "what's the difference" question; we already have [What is the difference between venv, pyvenv, pyenv, virtualenv, virtualenvwrapper, pipenv, etc?](https://stackoverflow.com/questions/41573587). – Karl Knechtel Aug 27 '23 at 18:02

2 Answers2

96

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 installed with pip.

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

If you use python3 I suggest to avoid any "extra" dependencies and just stick with venv.

Your error is probably because you use Python2/pip2.

fuzzy
  • 97
  • 6
Costantin
  • 2,486
  • 6
  • 31
  • 48
  • Thank you for this. If I delete my current python installation and reinstall Python 3.5 on my PC will it solve this issue? – Prince Kwekowe May 21 '17 at 00:08
  • Yes, probably, but if you give me the specific error I can tell you more precisely. However if you prefer to use python2 you can just use `virtualenv` which is pretty much identical to `venv` – Costantin May 21 '17 at 00:10
  • 1
    Thanks. I was missing "python" before the "-m venv". Now I understand the difference. – Prince Kwekowe May 21 '17 at 00:20
56

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 the "app-data seed method". See more about virtualenv Seeders in the docs.
  • venv can only be updated by 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.

Niko Föhr
  • 28,336
  • 10
  • 93
  • 96
  • 3
    Last part does feel like its not really valid? If i have x amount of python versions, i can still call any of those pythons directly with full paths and get a correct runtime paths for that particular interpreter. So, making a "venv" with that random python only requires that i know where that python is, say `~/localcopies/python/3.7.7/python -mvenv myproject` .. – rasjani Nov 11 '20 at 15:32
  • 3
    Yeah I agree. That was a bit misleadingly stated in the virtualenv docs. The difference is in the autodiscovery of python versions. I edited the answer. – Niko Föhr Nov 11 '20 at 21:11