[FFe] Upgrade to virtualenv 1.4.5

Debian does now have a more recent version in testing, 1.4.5. It sure would be nice to get this and #521170 fixed in Lucid.

In order to request a sync of Debian python-virtualenv 1.4.5 for Lucid we'll
need an FFe, and to do that, we'll need to know whether any of the
Ubuntu-specific changes in the python-virtualenv 1.3.3-1ubuntu2 are still
necessary. I've analyzed the three bugs fixed since the last sync to Debian's
python-virtualenv 1.3.3-1.

Bug 520337 - This does not seem to be necessary. When I built a virtualenv
with a simple test package (e.g. the one in bug 517390) I did not get the
crash described in bug 520337. However, I did need to modify the virtualenv
command to add the --distribute flag:

% virtualenv --distribute xx
% xx/bin/python setup.py install

This makes sense as our default setuptools is now distribute. I think we'll
need a patch to enable --distribute by default.

Bug 339904 - This one is no longer necessary because upstream virtualenv
contains this fix in 1.3.4:

 * Added support for the Debian/Ubuntu /usr/lib/pythonX.Y/dist-packages
   directory.

Bug 347203 - This one is no longer necessary either. I had no problems
building the Debian testing source package on Lucid with pbuilder.

In summary, I think we can and should approve an FFe to sync Debian
python-virtualenv 1.4.5 for Lucid, with a patch to enable --distribute by
default. I will create a branch for the latter, link it to this bug, and
request the FFe and sync.

> Bug 520337 - This does not seem to be necessary.  When I built a virtualenv
> with a simple test package (e.g. the one in bug 517390) I did not get the
> crash described in bug 520337.  However, I did need to modify the virtualenv
> command to add the --distribute flag:
>

From the virtualenv PyPi page at http://pypi.python.org/pypi/virtualenv/1.4.6

"You can also set the environment variable VIRTUALENV_USE_DISTRIBUTE
(since 1.4.4) and be a good Comrade"

Perhaps there is a way to take advantage of that?

Hi Maris. I don't think there's a good way to use $VIRTUALENV_USE_DISTRIBUTE because that would still require users to modify their environment to get anything useful on Lucid. I've linked a branch which keeps $V_U_D and --distribute, but enables them by default (essentially no-oping these options). It adds --setuptools and $VIRTUALENV_USE_SETUPTOOLS to get the old (default upstream behavior).

I will request an FFe for this branch.

For FFe:

* Upstream changelog is here: http://virtualenv.openplans.org/news.html
* Nothing reverse depends on python-virtualenv
* See my comment #2 above for relevance of Ubuntu related patches after upgrade (summary: they are unnecessary)
* Testing: I've built and installed 1.4.5 on Lucid and tested it with the test.sh script seen above, with all combinations of the relevant options and envar variables that I could find. I will upload the new package to my PPA so folks can test it, but it seems sound to me and definitely makes virtualenv usable on Lucid again.

python-virtualenv 1.4.5 with my change to enable --distribute by default is now available in my PPA:

https://edge.launchpad.net/~barry/+archive/python

Please test it and let me know if it works for you. That will help when trying to decide whether to grant the FFe.

Barry,

Have you examined the upstream delta, and can you tell us what the risks are here? (New features, bugfixes that required extensive changes and carry risk of regression)?

Hi Steve,

I haven't specifically looked at the diff from 1.3.3 to 1.4.5, but based on
the changes specified here <http://virtualenv.openplans.org/news.html>, this
is my take on it (note that since I last sync'd 1.4.7 has been released, but
that shouldn't affect us getting something that works on Lucid).

I should note too that python-virtualenv has no reverse depends.

1.4.5

    * Include pip 0.6.3
    * Fix activate.bat and deactivate.bat under Windows when PATH contained a parenthesis

Clearly we don't care about the Windows changes. What I don't know, but will
investigate is whether the updating of pip in virtualenv could cause conflicts
with python-pip 0.3.1 which is what we have in Lucid.

1.4.4

    * Include pip 0.6.2 and Distribute 0.6.10
    * Create the virtualenv script even when Setuptools isn’t installed
    * Fix problem with virtualenv --relocate when bin/ has subdirectories (e.g., bin/.svn/); from Alan Franzoni.
    * If you set $VIRTUALENV_USE_DISTRIBUTE then virtualenv will use Distribute by default (so you don’t have to remember to use --distribute).

The Distribute update matches what we have now. Same issue as before with
pip. I don't think we care about Setuptools since we already use Distribute.
Bug fix should be okay. The envar is directly related to the fixes we want
(though my branch enables Distribute by default so $VIRTUALENV_USE_DISTRIBUTE
and --distribute are a no-ops).

1.4.3

    * Include pip 0.6.1

Same pip question.

1.4.2

    * Fix pip installation on Windows
    * Fix use of stand-alone virtualenv.py (and boot scripts)
    * Exclude ~/.local (user site-packages) from environments when using --no-site-packages

Windows we don't care. The ~/.local exclusion looks like a useful, correct
bug fix. I don't specifically know what the second item is but it looks like
a bug fix.

1.4.1

    * Include pip 0.6

pip again.

1.4

    * Updated setuptools to 0.6c11
    * Added the –distribute option
    * Fixed packaging problem of support-files

I think we don't care about setuptools, and --distribute is exactly what we
want. I'd need to look at the details of the packaging problem fix, but it
doesn't seem like a new feature.

1.3.4¶

    * Virtualenv now copies the actual embedded Python binary on Mac OS X to fix a hang on Snow Leopard (10.6).
    * Fail more gracefully on Windows when win32api is not installed.
    * Fix site-packages taking precedent over Jython’s __classpath__ and also specially handle the new __pyclasspath__ entry in sys.path.
    * Now copies Jython’s registry file to the virtualenv if it exists.
    * Better find libraries when compiling extensions on Windows.
    * Create Scripts\pythonw.exe on Windows.
    * Added support for the Debian/Ubuntu /usr/lib/pythonX.Y/dist-packages directory.
    * Set distutils.sysconfig.get_config_vars()['LIBDIR'] (based on sys.real_prefix) which is reported to help building on Windows.
    * Make deactivate work on ksh
    * Fixes for --python: make it work with --relocatable and the symlink created to the exact Python version.

Don't care about Windows or OS X. The Jython items seem like bug fixes. We
need the dis-packages fix <wink>. The other two...

Thanks for the analysis, Barry. Please let us know what you find out about pip; as long as there's no problem there, I'm happy to grant this FFe.

Because of the way pip is installed it shouldn't matter. Pip is installed locally to the virtualenv and thus shouldn't affect the system pip, I've been upgrading pip in my old virtualenv installs and it's totally isolated.

@king_kilr: I concur. Outside the virtualenv we get the system pip. Once the virtualenv is activated we get the updated pip that comes with python-virtualenv. The whole point of virtualenv is environmental isolation and this seems to work as expected with the updated package.

Linking a branch with no substantive differences, but a better fidelity merge from lp:debian

Merge proposal: https://code.edge.launchpad.net/~barry/ubuntu/lucid/python-virtualenv/debsync-1.4.5-1/+merge/23789

This bug was fixed in the package python-virtualenv - 1.4.5-1ubuntu1

---------------
python-virtualenv (1.4.5-1ubuntu1) lucid; urgency=low

  * Enable --distribute by default but add --setuptools and
    $VIRTUALENV_USE_SETUPTOOLS to fallback to the default upstream
    behavior. (LP: #485944)
 -- Barry Warsaw <email address hidden> Mon, 19 Apr 2010 14:10:57 -0400

I tried installing Pinax 0.7.1 in a virtualenv using their script and it CRASHES EVERY TIME unless I remove python-setuptools and virtualenv (at which point it installs its own). It seems related to this (the version either being too old, or perhaps too new).

@hendrixski: Do you mean that with python-virtualenv 1.4.5 you're getting a crash? If so, can you please provide the traceback and a recipe for reproducing the problem?