[Distutils] How to handle launcher script importability?

[Vinay Sajip]

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.

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