[Python-Dev] Status of the built-in virtualenv functionality in 3.3

Vinay Sajip vinay_sajip at yahoo.co.uk
Thu Oct 6 18:46:34 CEST 2011


----- Original Message -----

> I started to play with virtualenv recently and wondered about the status
> of the similar feature in 3.3 (cpythonv).  The last thread mentioned two
> bugs; one has been fixed since.

The pythonv branch is pretty much up to date with the default branch (3.3). I regularly merge with default and post the results of running the Python regression suite in a virtual environment - in fact I'm running such a test right now :-). The test results and a screencast are linked from the project's BitBucket page at

https://bitbucket.org/vinay.sajip/pythonv/

> Apart from the implicit vs. explicit download of distribute, are there
> design issues to discuss?  Can we do that with a patch on a bug report?

I've made changes to get packaging to work well with virtualenv, some of which I raised as packaging issues on the tracker. In some cases, I've fixed them in the pythonv branch. The last bug is a problem with test_user_similar which has an existing issue (#9100) in a non-virtual environment. This is not a show-stopper, but I'm not really sure how the user scheme is supposed to work in venvs: perhaps Carl has a view on this. BTW there have been intermittent failures in test_packaging, too but they've generally been fixed by changes in core).


In terms of design issues, it would be useful if someone (apart from me that is) could look at how the pythonv fork differs from the core and comment on any issues they find. (Much of the change can be summed up as replacing occurrences of "sys.prefix" with "sys.getattr('site_prefix', sys.prefix)".)

BitBucket makes this type of comparison fairly easy to do; I'm not sure if there's a lot of value in adding a patch on the tracker for Rietveld review, until (and if) the PEP is accepted.


Re. distribute: At the moment the pythonv branch downloads a private version of distribute. The only significant difference from the vanilla distribute is the use of sys.site_prefix and sys.site_exec_prefix (falling back to sys.prefix and sys.exec_prefix if we're not running distribute in a virtual env, so it's backward compatible - but I didn't ask anyone in the packaging/distribute team to port this small change across. The only reference to sys.site_prefix is this code in setuptools/command/easy_install.py:

if hasattr(sys, 'site_prefix'):
    prefixes = [sys.site_prefix]
else:
    prefixes = [sys.prefix]
    if sys.exec_prefix != sys.prefix:
        prefixes.append(sys.exec_prefix)

If this were ported to distribute, that would be nice :-)

I think the plan is to remove the distribute-downloading functionality from the stdlib. However, I am working on a companion project, "nemo", which will have this functionality and in addition provides virtualenvwrapper-like functionality for Linux, Mac and Windows. (This is based on the stdlib API, is WIP, not released yet, though shown in the screencast I mentioned earlier).

> Oh, let’s not forget naming.  We can’t reuse the module name virtualenv
> as it would shadow the third-party module name, and I’m not fond of
> “virtualize”: it brings OS-level virtualization to my mind, not isolated
> Python environments.

I'm OK with Carl's suggestion of "venv", and prefer it to Brian's suggestion of "env".

Regards,

Vinay Sajip



More information about the Python-Dev mailing list