[Distutils] Using Wheel with zipimport

[Vinay Sajip]

Donald Stufft <donald <at> stufft.io> writes:

> I think we need to reconsider this. I cannot stress how badly an idea
> I think it is for Wheels to concern itself with the ability to add the
> Wheel to sys.path and import it.

I know that people have had bad experiences in the past with eggs, for the 
reasons Nick outlined in his response. However, you don't say *with 
specifics* why you think putting wheels on sys.path is a bad idea - I don't 
think it's convincing enough just to hand-wavingly reference problems with 
the egg format.

When this topic came up before, I asked for specific failure modes which 
were causing concern, but I never got a response IIRC.

One can't say that having the same packaging and importable formats is 
inherently bad, since Java shows otherwise. So if there are specific 
problems, they should be identified.

> Further more it won't even work accurately for all Wheels (as Nick's
> edit says) so we require that people wanting to do this figure out if
> their Wheel can or can not be added to the sys.path (which isn't as
> simple as looking at the tags because a platform specific Wheel may only
> contain optional C modules).

I don't yet see a technical impediment here. For example, distlib's wheel 
implementation uses a "mount" method to add a wheel to sys.path. This uses 
the tags to check for compatibility - there's no "figuring out" that the 
user has to do. If additional metadata about C extensions is available 
(which it is, if the wheel is built from source using distil), then those 
extensions are made available for import, too. I realise that's an extension 
to the current spec, but then no one is forcing any one to use it.

Regards,

Vinay Sajip