[Distutils] Disabling --single-version-externally-managed

[Phillip J. Eby]

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.