Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

python3 venv support #2

Open
MarSoft opened this issue Aug 7, 2017 · 1 comment · May be fixed by #4
Open

python3 venv support #2

MarSoft opened this issue Aug 7, 2017 · 1 comment · May be fixed by #4

Comments

@MarSoft
Copy link
Contributor

MarSoft commented Aug 7, 2017

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...

@MarSoft MarSoft linked a pull request Aug 7, 2017 that will close this issue
@randomir
Copy link
Owner

randomir commented Aug 7, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants