Python 3.4, ensurepip and wheels

[Bohuslav Kabrda]

----- Original Message -----
> > While trying to create the patch that would rebuild the wheels from
> > system and install them in venv, I bumped into few ugly problems, which
> > is why I came up with this "wheels in RPMs" solution in the first place.
> > I'd like to do this for 3.4 in Fedora and then start working on the
> > "file copying" solution that would be acceptable for upstream Python
> > 3.5. When this is done upstream, we will move to there with 3.5.
> 
> Alas, it sounds like the pip folks were right when they said "we're not
> sure that can actually work at this point" (something I hadn't thought
> about previously: at the very least, the install time shebang line
> rewriting and wrapper script generation will break. There's also the
> problem of *which* scripts get installed, since a system pip for Python
> 3 likely won't have the bare "pip" command, but we *do* want that in a
> virtual environment).
> 
> >     Creating the wheels from the files on the system keeps the number of
> >     copies of files to a minimum.  That, in turn, makes it easier for
> >     everyone involved to discover which files are the ones that do
> >     something.
> 
> So, here's a crazy thought: what if, rather than copying the installed
> files directly into the virtual environment, we reverse engineered a
> wheel archive *dynamically* from the system install and then installed
> from that? That would avoid the problems with trying to bypass pip's
> script generation, while still bootstrapping new virtual environments
> based on the installed versions of pip and setuptools.

There is a slight problem here:
In a stable Fedora release, we typically won't change pip's version, but rather backport security patches and the version will stay the same. So if you reconstruct the wheel from that, running "ensurepip --upgrade" in virtualenvs won't actually do anything, since pip will see the same version in virtualenv as is in the system and do nothing. There are few possible solutions to this:
- if version in system is the same as in virtualenv, check file checksums and if some differ, reinstall
- if version in system is the same as in virtualenv, uninstall pip in virtualenv and then reinstall the one from the system
- (ugly, not upstream acceptable) do "rpm -q python3-pip" and use the Fedora release as a "build tag" for reconstructed wheel (similar to what I proposed in the "bundled wheels" solution)
If upstream (you :)) accepts any of these types of behaviour (the second one seems the easiest and should work fine) in the PEP, I'll work on that.
Quite literally this time, we would reinvent the wheel :)

> Cheers,
> Nick.
> 
> --
> Nick Coghlan
> Red Hat Hosted & Shared Services
> Software Engineering & Development, Brisbane
> 
> Testing Solutions Team Lead
> Beaker Development Lead (http://beaker-project.org/)

-- 
Regards,
Bohuslav "Slavek" Kabrda.