> From: Donald Stufft <[email protected]> > 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 _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
