[Distutils] Multi-version import support for wheel files

[Vinay Sajip]

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

> I think I am against this.
> 
> Part of the beauty of Wheel is that it is simply a package format. This means
> it does not need to concern itself with situations that Egg had to which bloat
> the spec and make it harder to implement. I feel like tacking too much onto
> the Wheel format is going to end us up in the exact same place we are at with
> Eggs today. The more use cases we force onto Wheel the more we have to
> consider anytime we make a change. For instance with the proposed change
> now we have to worry about the importability of a Wheel file if an unpacked
> Wheel is added directly to sys.path which is something we currently do not need
> to worry about.
> 
> As far as I can tell there's nothing preventing Installing a Wheel *into* 
> and .egg
> directory which will give you exactly the same situation as you have today
> without needing to do *anything* except make a tool that will install a Wheel
> into an .egg directory. This solves your immediate desire without hanging
> more things onto Wheel.
> 
> Additionally I think the way it munges sys.path is completely backwards. I 
> believe,
> as you know, that the current order of the sys.path is somewhat nonsensical by
> default it goes ".", then standard library, then user site packages, 
> then regular
> site packages. I believe that the order should be ".", user-packages, 
> site-packages,
> and then standard library to provide a consistent ordering and allowing people
> to shadow packages using a hierarchy of specificity (the packages installed by
> a particular are more specific than the packages installed globally). However 
> when
> I brought this up to you you were insistent that the fact that user installed 
> code could
> not shadow the standard library was a feature and allowing it would be a bad 
> move.
> However that is exactly what this system does. The sys.path looks like (after 
> acting
> the cherrypy2 egg) ["cherryp2.egg", ".", stdlib, 
> user-packages, site-packages]. This
> is wrong by both your definition and mine.
> 
> So yea given that Wheels are not an on disk format, that you can install a Wheel 
> into
> and egg if you want, and that the sys.path munging required is several broken 
> I'm
> -1 on this. I do think we need a solution to multi version imports but I 
> don't think this
> is it. However I think it's perfectly valid to tell people that the new 
> tooling doesn't support
> this yet and they should continue to use the old. distutils2's problem was 
> they tried to
> solve everything at once let's not make our problem that we rushed to find 
> an answer
> for every problem and thus didn't fully flesh out all the options.

+1

Regards,


Vinay Sajip