You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is it possible to use python3 -m venv approach when creating virtualenv for python3? It is much faster (0.936s vs 2.464s on my system).
I see it is at least not straight-forward to implement, but it would be a nice feature.
P.S. Thanks for this tool, looks like it is the virtualenv manager I was looking for. According to docs it should fit my workflow exactly...
I think the difference in timings stems mostly from the fact that virtualenv is by default downloading latest pip and wheels, while venv is not.
See:
$ time python3 -m venv a
real 0m1.085s
user 0m0.964s
sys 0m0.076s
$ time virtualenv --python python3 --no-download b
Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /tmp/envs/b/bin/python3
Also creating executable in /tmp/envs/b/bin/python
Installing setuptools, pkg_resources, pip, wheel...done.
real 0m1.326s
user 0m1.224s
sys 0m0.092s
$ time virtualenv --python python3 c
Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /tmp/envs/c/bin/python3
Also creating executable in /tmp/envs/c/bin/python
Installing setuptools, pkg_resources, pip, wheel...done.
real 0m2.031s
user 0m1.872s
sys 0m0.148s
This not only slows virtualenv creation, but also introduces (sometimes great) variation in create times. Not to mention it doesn't work when the user is offline.
OTOH, the downside of --no-download option is that we're using system's pip, and probably not the latest version. But I'll prioritize mkenv speed (and working offline) over having the latest pip in env, because that's only one pip install -U pip away. Particularly now that I see pyvenv works like that too.
Now, regarding the pyvenv support, or even defaulting to it, for Python 3 -- I agree that's the way to go. However, I'm still not too familiar with pyvenv and since it does differ substantially from virtualenv (which is so deeply embedded in envie), a lot of testing still has to be done. (We'll be introducing a parallel mechanism for env create/find, making maintenance harder; user has to have ensurepip installed, which comes in a system package like python3-venv, I don't know how's the situation on MacOS; etc.)
Thank you for this good idea, I'll have a more detailed look.
Activity
randomir commentedon Aug 7, 2017
I think the difference in timings stems mostly from the fact that
virtualenvis by default downloading latestpipandwheels, whilevenvis not.See:
This not only slows virtualenv creation, but also introduces (sometimes great) variation in create times. Not to mention it doesn't work when the user is offline.
OTOH, the downside of
--no-downloadoption is that we're using system'spip, and probably not the latest version. But I'll prioritizemkenvspeed (and working offline) over having the latestpipin env, because that's only onepip install -U pipaway. Particularly now that I seepyvenvworks like that too.Now, regarding the
pyvenvsupport, or even defaulting to it, for Python 3 -- I agree that's the way to go. However, I'm still not too familiar withpyvenvand since it does differ substantially fromvirtualenv(which is so deeply embedded inenvie), a lot of testing still has to be done. (We'll be introducing a parallel mechanism for env create/find, making maintenance harder; user has to haveensurepipinstalled, which comes in a system package likepython3-venv, I don't know how's the situation on MacOS; etc.)Thank you for this good idea, I'll have a more detailed look.