[Distutils] How to handle launcher script importability?

[Donald Stufft]

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.

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.

> 
> As far as the advocacy for C-extension import support in wheel mounting
> goes, I see opposition to the idea on the basis that some people have shot
> themselves in the foot with a similar feature in pkg_resources. However,
> I've not seen any analysis that indicates (with specifics) why the feature
> is inherently bad (if there are problems with a specific implementation of
> the idea, then those could perhaps be resolved, but you can't really argue
> against "you're going to have a bad time, and you should feel bad").
> 
> Regards,
> 
> Vinay Sajip
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130821/27853a86/attachment.sig>