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

[Phillip J. Eby]

At 06:56 PM 8/31/2007 -0700, Toshio Kuratomi wrote:
>Phillip J. Eby wrote:
> > At 03:26 PM 8/31/2007 -0700, Toshio Kuratomi wrote:
> >>
> >> At this point I expect import sqlalchemy to import the 0.4 version and
> >> pkg_resources to give me access to 0.3.10 or 0.4.0beta4 depending on how
> >> I specify my versions.  But in fact, 0.4.0 is not available::
> >>
> >>   pkg_require >=0.3,<0.4.0beta1...  Traceback (most recent call last):
> >>     File "<string>", line 1, in <module>
> >>     File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 626,
> >> in require
> >>       needed = self.resolve(parse_requirements(requirements))
> >>     File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 528,
> >> in resolve
> >>       raise VersionConflict(dist,req) # XXX put more info here
> >>   pkg_resources.VersionConflict: (SQLAlchemy 0.4.0beta4
> >> (/usr/lib/python2.5/site-packages),
> >> Requirement.parse('SQLAlchemy>=0.3,<0.4.0beta1'))
> >>
> >> This also happens when I use *.pth files instead of installing 0.4 as an
> >> active egg.
> >
> > I'm not sure what you mean by using .pth files here.  If you did the
> > easy_install without the '-m', that would make the 0.3 version the
> > active (default) version, though, and it would override the
> > default-active 0.4 version.
> >
>I tried manually creating a .pth file that lists one or the other of the
>eggs.

That won't work to make the egg the default version.  You have to 
have easy_install generate the .pth file, so that the necessary magic 
is included.

Normally, paths in .pth files are added to the *end* of sys.path, 
which means the single-version egg will take 
precedence.  easy_install adds special incantations to its .pth files 
so that the eggs it installs have higher precedence than everything else.


>What determines if a version is active or inactive?


Whether it's listed on sys.path.  Your single-version egg's location 
was site-packages, and thus it's always on sys.path.


> > However, if you create a project that depends on the 0.3 SQLAlchemy, and
> > run a script from that project, it will see the correct version.
> > pkg_resources can resolve the version conflict automatically under those
> > circumstances.
> >
>If I understand you correctly, this is exactly the situation that is
>causing the error above.  I guess I should have been more explicit in
>what was being invoked to cause that traceback.  It's the second test in
>my test script:
>
>python -c 'import pkg_resources;
>pkg_resources.require("SQLAlchemy>=0.3,<0.4.0be
>ta1"); import sqlalchemy; print sqlalchemy.__version__'

Please reread what I said above: "if you create a *project* ... and 
run a script *from that project*".  That has nothing to do with what 
you're trying here, where you neither have a project nor a script 
generated from that project.  (You don't even have a script!)

The script wrappers generated by easy_install have code that handles 
this conflict issue.  Your test does not.


> > Anyway, the point here is that a default version is a default version,
> > period.  The only way it can be overridden is by a conflicting
> > requirement defined for a script.
> >
>1) Is the default version different from the active version?  If so how?

A default version is the version that's active by default.  :)  If 
it's listed in a .pth *generated by easy_install*, it will be the 
default version.  Otherwise, if it's a single-version egg on 
sys.path, it will be the default version.  Otherwise, if it's listed 
in a handmade (non-magic) .pth file, it will be the default 
version.  If it's somehow otherwise put on sys.path, it will be the 
default version.  If none of the above apply, there is no default version.


>2) Is what I'm doing above with pkg_resources.require() what you mean by
>specifying a conflicting requirement?

No.