[Distutils] Wheels and console script entry point wrappers (Was: Replacing pip.exe with a Python script)

Paul Moore p.f.moore at gmail.com
Tue Jul 16 15:08:43 CEST 2013

On 16 July 2013 13:42, Ronald Oussoren <ronaldoussoren at mac.com> wrote:

> > On the other hand, I'm missing something, as I don't see how the
> *current* exe wrappers avoid meaning that there need to be separate 32-bit
> and 64-bit versions of pip...
> Couldn't you just ship both variants of the exe wrappers in a single
> distribution and then use the correct one for the current installation?
> That's what I'm doing in py2app.

That's OK for source-style installs (which is what setuptools does, and
what pip mostly cares about right now). But for bundling with Python it
needs to be considered (although it's just getting the right one in the
right installer). But for wheels it's a pain, because instead of having
just a single pip wheel, we need 32-bit and 64-bit wheels solely for the
wrappers. That sucks. Hard. (And it's not just for pip, nose will have the
same problem, as will many other projects that use exe wrappers). And the
bdist_wheel command currently doesn't recognise this *at all*. So wheels
using wrappers are potentially broken.

I think the correct solution is to explicitly have declarative support for
"console script entry point" metadata in PEP 426, as well as having tools
like bdist_wheel and distil do some explicit backward compatibility hacking
to remove legacy-style exe wrappers. The wheel install code should then
explicitly install appropriate wrappers for the target platform (which may
be exe wrappers similar to the current ones, but moving forward may be some
other mechanism if one is found).

This is complex enough that I'm now concerned that we need reference "wheel
install" code in the stdlib, just so that people don't make up their own on
the basis that "wheel is simple to install manually" and screw it up. Also
so that we only have one style of command line script wrapper to deal with
going forward, not a multitude of mostly-compatible solutions.

Nick: See the above point re PEP 426 - do you agree that this needs
addressing in Metadata 2.0?


PS There is still the proviso that I haven't tested my assumption that the
separate 32 and 64 bit wrappers are *needed* (setuptools and distlib use
them, so I think it's a valid assumption, but I need to test). I will try
to get time to check that ASAP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130716/35f9c3d1/attachment.html>

More information about the Distutils-SIG mailing list