On Aug 25, 2013, at 1:57 AM, Nick Coghlan <[email protected]> wrote:
> I'm currently working on the docs for the __main__.__requires__ > feature of pkg_resources, and have been generally poking around inside > pkg_resources before I started on that. It gave me an idea for a > question that has come up a few times: how should we support parallel > installation of multiple versions of the same distribution in the same > Python installation, *without* requiring complete isolation in the > form of virtual environments. > > The current solution (at least in Fedora), is to use the multi-version > support in pkg_resources by installing unpacked egg files. To use > CherryPy as an example, Fedora currently provides RPMs for both > CherryPy 2 and 3. > > CherryPy 3 is the default and installed directly into site-packages, > with an appropriate .egg-info directory > > CherryPy 2 is *not* the default, and is instead installed as an > unpacked "CherryPy-2.3.0-py2.7.egg" directory. You can force this > directory to be added to sys.path by doing the following in your > __main__ module: > > __requires__ = ["CherryPy < 3"] > import pkg_resources > > (__main__.__requires__ *has* to be set before importing pkg_resources > or the default CherryPy 3 module will be activated automatically, and > conflict with a later call to pkg_resources.requires that asks for > CherryPy 2) > > While I'm not a fan (to put it mildly) of non-trivial side effects > when importing a module, this approach to multi-version imports *does* > work well (and, as noted, I'm currently working on improving the docs > for it), and I think the approach to the filesystem layout in > particular makes sense - the alternative versions are installed to the > usual location, but pushed down a level in a subdirectory or zip > archive. > > So, it seems to me that only two new pieces are needed to gain > multi-version import support for wheel files: > > 1. An option (or options) to pip, telling it to just drop a wheel file > (or the unpacked contents of the wheel as a directory) into > site-packages instead of installing the distribution directly as the > default version. The "root_is_purelib" setting in the wheel metadata > would indicate whether the destination was purelib or platlib. A wheel > installed this way wouldn't have script wrappers generated, etc - it > would only allow the contents to be used as an importable library. > > 2. Support for the ".whl" filename format and internal layout in > pkg_resources, modelling after the existing support for the ".egg" > filename format. For wheels that include both purelib and platlib, > this would involved adding both directories to the path. > > That means there wouldn't be an major design work to be done - just > replicating what easy_install and pkg_resources already support for > the egg format using the wheel format instead. > > Regardless of my personal feelings about the current *front end* API > for multi-version imports (and PJE has put up with my ranting about > that with remarkably good grace!), the current egg-based back end > design looks solid to me and worth keeping rather than trying to > invent something new for the sake of being different. > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > _______________________________________________ > Distutils-SIG maillist - [email protected] > http://mail.python.org/mailman/listinfo/distutils-sig 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. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
