Is python package virtualenv necessary when I use python 3.3?
Question:
I was looking in Cristoph Gohlke’s python packages and I noticed that there is a package Virtualenv for Python 3.3.
Since there is a package venv in the standard python library v3.3, I was wondering if there is an advantage to install this package separately.
Edit: From the documentation of both packages, virtualenv 1.8.2 and venv I can say that the venv standard library package lacks the functionality of:
--no-site-packages option- choice between setuptools or distribute
- inability to install pip, since it is not available in the default python installation
- no customization of prompt prefix inside the virtual environment
--prompt=PROMPT
If there are any other differences that I was unable to spot, please write them here.
Answers:
Generally, the virtualenv package is not required when using python3.3 or later, since it was incorporated into the standard library via PEP 405. As you note in the question, there are some relatively small differences between the latest versions of virtualenv and the venv package in the standard library. In part (e.g. --no-site-packages) this stems from the different implementations. Since venv is in the standard library, it doesn’t have to jump through some of the contorted hoops that virtualenv does in order to create a self-contained python installation, such as copying much of python’s site module.
The best resource is really to read the PEP thoroughly.
for the question
Is python package virtualenv necessary with venv in the stdlib?
(or what are the differences?)
--no-site-packages is the default in both. The --system-site-packages option exists, but it’s broken- distribute is deprecated… nothing to see here
- Since Python3.4, ensurepip will provide pip inside the virtualenv. To get it working on Ubuntu/Debian, be sure to install the
python3-venv package
- No changes here
When venv was first announced, I’d hoped that it get into maintenance mode, to provide bug fixes on the “virtualenv for old pythons”, and all developments would shift focus on the stdlib venv. I’m not sure about the project goals/roadmap for virtualenv, but I’m afraid that what I hoped is not happening. So, at least for the time being, I’d keep using the original virtualenv.
pyvenv was the recommended tool for creating virtual environments for Python 3.3 and 3.4
From python 3.5 onwards use:
python3 -m venv
venv is an inbuilt module with access to python’s internals
pyvenv is deprecated in 3.6
I was looking in Cristoph Gohlke’s python packages and I noticed that there is a package Virtualenv for Python 3.3.
Since there is a package venv in the standard python library v3.3, I was wondering if there is an advantage to install this package separately.
Edit: From the documentation of both packages, virtualenv 1.8.2 and venv I can say that the venv standard library package lacks the functionality of:
--no-site-packagesoption- choice between setuptools or distribute
- inability to install pip, since it is not available in the default python installation
- no customization of prompt prefix inside the virtual environment
--prompt=PROMPT
If there are any other differences that I was unable to spot, please write them here.
Generally, the virtualenv package is not required when using python3.3 or later, since it was incorporated into the standard library via PEP 405. As you note in the question, there are some relatively small differences between the latest versions of virtualenv and the venv package in the standard library. In part (e.g. --no-site-packages) this stems from the different implementations. Since venv is in the standard library, it doesn’t have to jump through some of the contorted hoops that virtualenv does in order to create a self-contained python installation, such as copying much of python’s site module.
The best resource is really to read the PEP thoroughly.
for the question
Is python package virtualenv necessary with venv in the stdlib?
(or what are the differences?)
--no-site-packagesis the default in both. The--system-site-packagesoption exists, but it’s broken- distribute is deprecated… nothing to see here
- Since Python3.4, ensurepip will provide pip inside the virtualenv. To get it working on Ubuntu/Debian, be sure to install the
python3-venvpackage - No changes here
When venv was first announced, I’d hoped that it get into maintenance mode, to provide bug fixes on the “virtualenv for old pythons”, and all developments would shift focus on the stdlib venv. I’m not sure about the project goals/roadmap for virtualenv, but I’m afraid that what I hoped is not happening. So, at least for the time being, I’d keep using the original virtualenv.
pyvenv was the recommended tool for creating virtual environments for Python 3.3 and 3.4
From python 3.5 onwards use:
python3 -m venv
venv is an inbuilt module with access to python’s internals
pyvenv is deprecated in 3.6