Python 3.4, ensurepip and wheels

[Toshio Kuratomi]

On Dec 10, 2013 6:26 AM, "Bohuslav Kabrda" <bkabrda at redhat.com> wrote:
>
> ----- Original Message -----
> > On 11/28/2013 12:42 AM, Bohuslav Kabrda wrote:
> > > I hope I covered all the important points. Basically, we can make
this work
> > > in a way acceptable for upstream, if we package setupttols and pip as
> > > wheels. It'll require some extra effort, but I think it's worth it.
> > > Thoughts? Anyone has better/simpler ideas?
> >
> > From an upstream point of view, so long as test.test_ensurepip and
> > test.test_venv still work, things should generally be OK.
> >
> > I quite like the idea of checking for the consistency of the RECORD
> > files between the system pip and the one in the virtualenv (as well as
> > using RECORD as a guide to what to copy into a fresh venv). If you get
> > that working, I'd be interested in a Python 3.5 venv and/or ensurepip
> > patch to do that by default, and only bootstrap from the embedded wheel
> > if there was no system pip available.
> >
> > Cheers,
> > Nick.
>
> Actually, there seems to be a much simpler way of doing this in Fedora
(and any distro more generally):
> - setuptools and pip RPMs will carry the wheel inside them and drop it
into ensurepip/_bundled
> - the wheels will be rebuilt during every RPM build everytime *after
patching*, so they will carry security patches etc.
> - we will use the RPM release as the "build tag" mentioned in PEP 427
[1], so that when we e.g. fix a security bug but don't bump the version,
"ensurepip --upgrade" will still see that the wheel has to be reinstalled
(otherwise it'd say think the version is already there and wouldn't
reinstall)
> So the only thing we will need to implement will be autodiscovery of the
wheels, since they will change names independently on python3 package, but
I think we can do that :) From upstream point of view this shouldn't break
anything, but it'd also probably not have any benefit. Would you still
accept such patch?
>

Note that this misses one thing mentioned in my mail: local changes.

Because scripting languages are readable and modifiable, sysadmins will
sometimes fix bugs that affect them by deploying just the changed .py files
(rather than rebuilding an rpm package).  Configuration management (puppet,
Ansible, chef, etc) makes it easy to deploy and track hotfixes this way.
If wheels are cached at rpm buildtime then this workflow will cease to
function correctly for virtualenv and these bundled libraries.  Since the
bundling is an implementation detail that sysadmins will have no reason to
know about until they want to hotfix whichever libraries are bundled, this
is likely to take them a while to figure out.

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.

-Toshio

> Regards,
> Slavek.
>
> [1] http://www.python.org/dev/peps/pep-0427/#id11
> _______________________________________________
> python-devel mailing list
> python-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/python-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/python-devel/attachments/20131210/d47f5189/attachment.html>