On 21 August 2013 07:36, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
Donald Stufft <donald <at> stufft.io> writes:

> Mounting Wheels seems like a bad idea, it was one of the things Daniel
> explicitly removed (since Wheels are basically cleaned up eggs). Adding
> it back in ex post facto seems like it's an idea that's going down the wrong
> track.

Like I said, the sky will fall. Isn't importing from zips what's being
discussed in this part of the thread?

Unless something is expressly verboten, I can't see a reason why particular
implementations of a PEP can't provide additional functionality, as long as
they implement the contents of the standard. And in Python's
consenting-adults world, I can't recall seeing any such express proscriptions.

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.

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

Paul

PS Variances like this make me want to go back to the original idea that wheel support functions should be implemented in the stdlib, rather than having competing implementations "in the wild". Or at least, that one implementation should be considered the reference implementation that all others need to be compatible with :-(