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.