[Distutils] Disabling --single-version-externally-managed
Phillip J. Eby
pje at telecommunity.com
Sun Sep 2 03:01:35 CEST 2007
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_ 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.
> >> .. _: 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
>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.
More information about the Distutils-SIG