[Distutils] How to handle launcher script importability?

[Nick Coghlan]

On 21 Aug 2013 17:46, "Donald Stufft" <donald at stufft.io> wrote:
>
>
> On Aug 21, 2013, at 3:32 AM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
>
> > Paul Moore <p.f.moore <at> gmail.com> writes:
> >
> >> I'm concerned that you need extra metadata (not described in the wheel
> > spec) to do this. It means that there are in effect two subtly different
> > types of wheel. To be specific, if I create a wheel for (say) pyzmq
using
> > distil, and mount it, everything works. But if I create the same wheel
with
> > bdist_wheel or pip, it doesn't. That, to my mind, is very bad as it
damages
> > the credibility of wheel as a standardised format.
> >
> > If the additional metadata isn't there, then distlib just doesn't do
> > anything additional - it just makes the Python modules importable (by
adding
> > the wheel to sys.path, which AFAIK is uncontroversial).
> >
> >> Can I suggest that if you need to add features like this, you need to
get
> > the wheel spec updated to mandate them, so that *all* wheels will
follow the
> > same spec.
> >> Essentially, I am -1 on any feature that uses information that is not
> > documented in the wheel spec. Pip in particular resisted adding support
for
> > wheels until they were standardised in a PEP. It's frustrating if that
PEP
> > *still* doesn't mean that the wheel format is the same for all tools.
(Note
> > that another area where this is an issue is script wrappers, as the
spec is
> > silent about the fact that they are specified using entry-points.txt in
> > metadata 1.x/setuptools. I've sent a proposed update to the spec to
Daniel
> > for his consideration).
> >
> > Well, you don't really want to stifle innovation, do you? ;-)
> >
> > As far as I can tell, Daniel's wheel implementation allows files that
are
> > not specifically mentioned in the PEP to be installed into a
distribution's
> > .dist-info. This is also allowed in distlib - ISTM this is one way in
which
> > different packaging tools can add features which are special to them,
and
> > hold state relevant to distributions they build and/or install. If you
> > accept that multiple competing implementations if a PEP are a good
thing,
> > then they can't all be functionally identical, though they must all
> > implement a common set of functions described in the PEP they're
implementing.
>
> I was one of the advocates for extension support in the new metadata, I
want
> tools to be able to try things out and innovate.
>
> However what I don't really want is to be using someones personal testbed
> for features they think is cool. There's nothing *wrong* with you trying
new
> ideas out in distlib, it just means that distib isn't the library I want
to build
> tooling around.

Right. I wasn't really aware Vinay was adding experimental ideas to
distlib, I thought it was just the proven stable core from distutils2, plus
support for the draft PEPs, with the experimental stuff entirely in distil
rather than in distlib.

If Vinay wants to do experimental extensions, they either need to happen
somewhere other than distlib, or else we need a new library which is just
the candidate for standard library inclusion with *nothing* that hasn't
been discussed and agreed to through the PEP process.

As I said, I *thought* distlib was that library, but it appears Vinay
doesn't currently see it that way :(

>
> 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.

Right. distlib can be a candidate for stdlib inclusion, or it can be a
vehicle for distributing experimental features not covered by any PEP, it
can't be both at the same time.

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130821/9668f5f5/attachment-0001.html>