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

Toshio Kuratomi a.badger at gmail.com
Sat Sep 1 03:56:00 CEST 2007

Hash: SHA1

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

>> Is this a bug?
> Not really.  Once pkg_resources has been imported, it's too late to
> request an inactive version that conflicts with an active version of the
> same project, as the default working set has already been configured by
> that time.
What determines if a version is active or inactive?

> 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;
ta1"); import sqlalchemy; print sqlalchemy.__version__'

> 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?
2) Is what I'm doing above with pkg_resources.require() what you mean by
specifying a conflicting requirement?
2b) If so, is it a bug that it doesn't work?

- -Toshio
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the Distutils-SIG mailing list