[Distutils] Wheel support added to distlib

[Daniel Holth]

On Wed, Feb 20, 2013 at 12:33 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Wed, Feb 20, 2013 at 10:18 AM, Daniel Holth <dholth at gmail.com> wrote:
> > Wheel is only defined for 1 dist per archive.
>
> Indeed. We did briefly discuss the idea of wheels-within-wheels
> somewhere along the line (it may even have been a private email
> conversation I had with Daniel about an early version of the wheel
> spec), but we ultimately decided it was an aspect of the problem
> better left until later.
>
> This was at least partly due to the fact that bundling dependencies is
> still evil in many situations, as it's a nightmare for security
> updates if you don't get the related packaging tool design right.
>
> If we do decide to tackle that use case for a hypothetical wheel 1.1
> release, I'd push for a literal wheels-within-wheels solution: add a
> {distribution}-{version}.dependencies folder to the spec, and dump the
> wheel archives for any bundled dependencies in there. Installation
> tools can then consider that folder as a possible source for
> distributions, in addition to already installed distributions and any
> online indexes. Once installed, updates would work normally, helping
> to avoid the "security updates for bundled distributions are
> difficult" problem.


Check out logstash. It is a huge Ruby application that uses lots of gems.
Never mind that it is JRuby... the end user experience is that you download
an archive, run it, wait, and it all works without any installing at all.
Compare to installing an application into a new virtualenv with only a list
of dependency names which is more like passing through death and fire.

Long story short there's potential here. It's been done before of course
with things like py2exe but look! Wheel! Reinventing is the name of the
game.

For example you could write a __main__.py that would scan the archive for
embedded wheels and add them to PYTHONPATH pkg_resources-style, choosing
different platform-specific ones depending on the environment. Not sure if
.whls would have to be a PEP format, it could just be a useful py2exe
alternative / standalone Python application format. The current format was
enough to keep us busy until now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130220/3e73293c/attachment-0001.html>