[Distutils] How to handle launcher script importability?

[Paul Moore]

On 21 August 2013 11:56, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:

> > But I think we have a reasonable consensus on how scripts should work,
>
> Do we?


To the level of "wheels builders should write metadata that defines the
scripts and wheel installers should generate the necessary wrappers" then
yes.

We may or may not (depending on your viewpoint) have agreement on the
format of that metadata. Personally, I think that Metadata 2.0 where the
wheel uses that format, and entry-points.txt for older versions, is the
only realistic option here.

I would like to see some clarity on the status of the wheel 1.0 spec. Where
there are areas like this where the spec is either silent or missing
sufficient detail to allow us to implement a common approach, should we be
updating the 1.0 spec or should we be creating a 1.1 spec (I'd prefer the
former)? Who does those updates? Must they go through Daniel as the author
(who's been quite quiet, possibly he's hiding somewhere rather than being
drawn into the fray :-))?


> Someone might tell me tomorrow that the "cool" one-executable
> solution I've recently implemented as an option on Windows (append shebang
> /
> archive to a stock executable) is an offence against all that's holy ;-)
>

That won't be me. I'm more interested in discussions about interoperability
issues than about how the functionality gets implemented.

> 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).
>
> If distlib is proving to be a problem either as a producer or consumer of
> wheels, please raise issues.
>

I don't believe that distlib creates scripts based on entry-points.txt for
pre-2.0 metadata. I have raised an issue for that. That's the only
significant issue I have with distlib from the POV of what it can solve.
There may be other interoperability issues where other tools can't consume
things that distlib produces - I haven't tested anything like all of the
combinations. We currently have 2 producers and 3 consumers. That's already
6 interactions to test. And if there *is* an issue, it's not always at all
clear who to report the problem to.

I'm not complaining about *any* of the implementations here. And I
apologise if you in particular feel "picked on" (there's probably a
distutils-sig "victim of the week" rota somewhere for this ;-)) My real
concern is that we're drifting away from standards-based design towards
implementation-based. And I think that updating the wheel PEP to be tighter
on some of the details is what's really needed (hey, look, it's Daniel's
turn to be picked on! :-))

I'd be willing to author an updated version of the wheel spec if all of the
interested parties are OK with that (in particular, Nick and Daniel). If
nothing else, that means that everyone can pick on me so I wouldn't feel
quite so much like a troublemaker :-)

Paul

PS I really, really don't want anyone here to feel like anything they do is
not valued. This is about tidying up the documentation, not about stifling
anyone's enthusiasm or blocking any experimentation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130821/8983d4d5/attachment.html>