[Distutils] How to handle launcher script importability?

[Paul Moore]

On 21 August 2013 08:45, Donald Stufft <donald at stufft.io> wrote:

> My basic problem is if the library we're pointing at to be the reference
> implementation of all of these things is adding new features it's
> confusing what
> is standard and what are just distlib's extensions.
>
> So basically I want people to innovate, that's something I feel very
> strongly
> is a good thing, I just don't want innovations to happen in the reference
> library. Maybe we need a smaller reference library which is strictly the
> PEPs
> to allow distlib to experiment. If it's experimentations turns out to be
> good and
> useful we can make PEPs for them and add them to the reference library.
>

+1

My problem is that as someone who wants to implement code that uses the new
features like wheels, I want a usable reference implementation that covers
the (agreed) standards. I don't particularly want my application to
incorporate support for extensions to the standard, nor do I want to have
to implement my own support all the time.

In particular, at the present time there are two tools that can generate
wheels (bdist_wheel and distlib) and 3 that can install them (wheel,
distlib and pip). They have subtly different behaviours outside of the
standard definitions, which means that they are not completely
interoperable. I am not happy at all about that - and if that counts as
"being against innovation", then I'm afraid that yes, I am... (I don't
think it does, by the way, but you may differ).

At the moment the wheel PEP is lagging a little behind some of the ongoing
discussions, in particular in terms of script generation. That's fine, it's
a work in progress. I hope it will be updated soon so that the spec matches
what's been agreed. But I think we have a reasonable consensus on how
scripts should work, and I think that should be reflected in the spec and
the various tools be brought up to date with the spec before we move onto
other areas and forget to tidy up around this one. Pip resisted including
wheel support until we had a standard. I'm pretty unhappy that now we do
have a standard, we still have situations where a wheel generated by one
tool can have problems when installed with another - try "pip install wheel
--use-wheel" on Windows to see what I mean, the exe wrappers are missing
(this uses the wheel from PyPI, not a home-built one).

OK, so here's a concrete question for distutils-sig. If I want to use
wheels in my app (built them, install them, whatever) what should I use as
my "reference implementation". I don't want to implement the code myself, I
just want to produce lowest-common-denominator wheels that can be used
anywhere, and consume wheels that conform to the spec correctly. This is
not a hypothetical question - in the first instance I'm looking to add
support for loading setuptools/pip from wheels in virtualenv, and I need to
know what code to bundle to make that happen.

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130821/3cc5cdea/attachment-0001.html>