At 02:09 PM 9/1/2007 -0700, Toshio Kuratomi wrote: >Phillip J. Eby wrote: > > At 09:20 PM 8/31/2007 -0700, Toshio Kuratomi wrote: > >> Just to illustrate what I'm trying to achieve. I've updated the Fedora > >> Packaging Guidelines[1]_ to allow two versions of a package to coexist. > >> I'll list here the sqlalchemy-0.4 and -0.3 build steps, filelists, and > >> the output of the test-sql.sh script using this procedure. The end > >> result is what we want but the build step to get there seem a tad > >> fragile and kludgey. Since these are going to become guidelines for all > >> of our python packages, I'd like to know if either: 1) there's a better > >> way to do this or 2) the results I'm achieving are not expected and > >> could disappear with a random upgrade of setuptools. > >> > >> .. _[1]: http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs > > > > Here's the thing: if you want multiple installed versions of a package, > > *and* you want there to be a default version, then you *have* to have > > easy_install (or zc.buildout, or some similar tool) generate the startup > > scripts for anything that wants to use a non-default version. > > >You'll have to explain why that is because all my experiments show that >to be false. Installing one package via easy_install -m and another via >- --single-version-externally-managed gets us 75% of the way to this >working. Using easy_install -m for both and then copying/symlinking >gets us 100% of the way.
I don't understand what you're saying. If you have multiple versions installed, and one of them is active by default (i.e., listed in a .pth, or a single-version in site-packages), then the only simple way to access the non-default version is via an easy_install-generated script. >Since the working_set doesn't explicitly list eggs unless they are >specified in a project's requires.txt it seems like >pkg_resources.require() can override a module which is the default >because it is installed in site-packages. In fact, I understood this to >be a feature of setuptools: allowing someone to override the vendor >installed packages in site-packages with your own eggs. It is -- but as I said, it only works for scripts generated by easy_install, if you want to import the non-default version. > > Thus, if you want multiple versions *and* want to be able to select a > > version after pkg_resources has been imported, you *cannot* have a > > default version. In other words, the egg must not be on sys.path when > > pkg_resources is imported. Then, pkg_resources can locate the desired > > version and add it. > > >Not quite. In the single-version case, the egg is on sys.path because >the module directory is in site-packages. Therefore pkg_resources make >a different version importable by placing a different egg's path before >site-packages in sys.path. Again, that's *only* if you don't have a conflicting egg that's already the default. >The goal is to have all of these things work: >1) import MODULE should import whatever the vendor decided should be the >default. >2) requires.txt in a project's egginfo should work to select a specific >version from the installed eggs. >3) In a simple script (without requires.txt), pkg_resources.requires() >should work to select a specific version from the installed eggs. #1 and #2 are easy. #3 is possible only if you use the hack that easy_install-generated scripts use. >For 3) No eggs for this module can be on sys.path before the >pkg_resources.require() call. This does not count modules brought in >via site-packages as those are going to be overridden when we place egg >paths before site-packages. Yes it *does too* count, which is why it doesn't work as you expect. >You seem to think there's something wrong with this so there's obviously >something you're seeing that I don't. Can you give an example of where >this will fail? Any time you expect to be able to import the non-default version of a package, and you either run the interpreter with no script, or run a script that wasn't generated by easy_install or otherwise hacked to work around the conflict issue. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig