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

Toshio Kuratomi a.badger at gmail.com
Sun Sep 2 04:45:22 CEST 2007

Hash: SHA1

Phillip J. Eby wrote:
> At 02:54 PM 9/1/2007 -0700, Toshio Kuratomi wrote:
>> Toshio Kuratomi wrote:
>> >
>> > This code creates an unordered list because you might have already had
>> > to place something after one of the duplicate locations that this code
>> > is removing.  We need to do a sort of the entire list after each add +
>> > duplicate removal run.
>> Here's a quick and dirty patch.  It's correct but it's inefficient.  A
>> better sort algorithm would help some.  Refactoring code so we call a
>> sort method after we finish adding entries to the path would be even
>> better.
>> I'll test how this affects packaging tonight.
> Please, please stop and back up a minute.   appreciate your eagerness to
> help, really, but right now I can't trust the correctness of the initial
> system against which you are performing your tests.  You've got crazy
> stuff on sys.path, you appear to be calling insert_on() (which isn't a
> documented API), and you're manually creating .pth files, among other
> things.
Well, *I'm* not calling insert_on().  setuptools is calling insert_on()
when it initializes via __requires__ = "TurboGears"; import
pkg_resources (I did not write that script, it's tg-admin from TurboGears.)

I just instrumented the pkg_resources() code to figure out what's going
on and found sys.path being updated incorrectly.

As for manually created .pth files, all the ones I created were removed
right after I tested that they didn't work.  None of the results I've
posted involved them.  However, there are .pth files that were generated
by other people's packaging.  I'll go through and remove or fix all of
those packages on my system.

> So before you do anything else, please restore your system to something
> which consists *only* of files generated by setuptools or easy_install
> without *any* added hacks, workarounds, or manually edited files.  That
> also means NO scripts that were not generated by easy_install.
Uhm... I can get rid of the two packages that I changed and take care of
the .pth files but really unless I remove everything but python and
setuptools from this system, there's going to be packages that were
built with distutils, setuptools, configure scripts, and etc here.
Everything is managed via rpm so I could do that but I'd rather know
what in particular I need to get rid of.  (Like: Remove anything that
installs a .pth file.)  If you say remove everything that installs an
egg that I haven't audited how it builds I can do that pretty easily.

> If you *must* have other scripts, there is an undocumented internal
> feature that you can use to specify a script's requirements such that
> they override the default package versions.  What you have to do is add
> a __requires__ definition to the script, e.g.:
>    __requires__= 'TurboGears>1.0', 'FibbledyDee<27.2'
> This definition must be in the actual script run by Python.  When
> pkg_resources is initially imported, any __requires__ requirements are
> given higher precedence than the default versions.  You must, however,
> still import pkg_resources, and it must be imported *after* setting
> __requires__, not before.
> Assuming I understand your requirements, you should be able to
> accomplish everything you want using only this one feature, plus
> single-version eggs for system default packages, and multi-version eggs
> (i.e. *no* .pth files) for everything else.

Does this work from the interpreter shell?
>>> __requires__ = 'SQLAlchemy>=0.3,<0.4beta1'
>>> import pkg_resources
>>> import sqlalchemy

That might do the trick but it's not ideal for us to drop support for a
documented interface in favor of an undocumented one.  I'm writing
guidelines for packagers, not programmers.  By and large, we're not
writing scripts, we're packaging python modules so that people who are
writing scripts can get their work done.  It's important that the
documented way of doing things works.

pkg_resource.requires() is documented on the web page, in
pkg_resource.txt, and when you python setup.py install
- --single-version-externally-managed.  __requires__ is documented...
nowhere.  If you're willing to change documentation that says to use
pkg_resources.require() to use __requires__ instead then this will work
out perfectly.  If not, we'll need to find a way to make
pkg_resources.require() work so that we aren't constantly explaining to
people that it doesn't work because upstream tells us it doesn't work
and we're sorry that all the official upstream documentation says otherwise.

> It should not be necessary for you to generate or edit any files, use
> other undocumented APIs, or anything else.
That's the unstated goal that goes along with the other three :-)

Do you IRC?  I'll fix and remove packages and then tell you what still
works and 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