[Distutils] How to handle launcher script importability?

Nick Coghlan ncoghlan at gmail.com
Wed Aug 21 23:01:40 CEST 2013

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
> > distil, and mount it, everything works. But if I create the same wheel
> > bdist_wheel or pip, it doesn't. That, to my mind, is very bad as it
> > 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
> > the wheel to sys.path, which AFAIK is uncontroversial).
> >
> >> Can I suggest that if you need to add features like this, you need to
> > 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
> > wheels until they were standardised in a PEP. It's frustrating if that
> > *still* doesn't mean that the wheel format is the same for all tools.
> > 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
> > 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
> > not specifically mentioned in the PEP to be installed into a
> > .dist-info. This is also allowed in distlib - ISTM this is one way in
> > different packaging tools can add features which are special to them,
> > hold state relevant to distributions they build and/or install. If you
> > accept that multiple competing implementations if a PEP are a good
> > then they can't all be functionally identical, though they must all
> > implement a common set of functions described in the PEP they're
> I was one of the advocates for extension support in the new metadata, I
> 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
> 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
> 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
> 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.

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

More information about the Distutils-SIG mailing list