The best way is going to convince deb packagers to include the egg info so that setuptools can see that the package is in place. Each package comes with its own meta-data.

Indeed, this looks like the right way (tm), but in the meantime wouldn't it be reasonable to include a transition mechanism?

I'm certain Fedora will be heading in this direction.

I'll try to see if there is something pending for debian (python-setuptools is part of testing, so...) [...dig dig dig...] Yuck, I hope to find something more positive than that: <http://mail.python.org/pipermail/distutils-sig/2005-November/005470.html> :-( Frédéric -- Frédéric Gobry Infoscience SISB / EPFL Tel: +41216932288 http://people.epfl.ch/frederic.gobry

Frédéric Gobry wrote:

I've started using setuptools as a developer quite recently, and appreciate the extra features. I've a question though, regarding the way dependencies are resolved when installing such a package: I've written a package that uses elementtree, and would have found natural to add it in install_requires. However, I've already installed it as a debian package, and in the current state setuptools tries to reinstall over it.

Note that it doesn't install *over* it at all. A normal "python setup.py install" without setuptools and with Debian's default distutils.cfg *will* install over it, but with setuptools/easy_install it will not. If you install multiversion (-m to easy_install) then you won't really have effected the system at all except for packages that specifically require ElementTree through setuptools mechanisms. Altogether it is much lower impact than normal distutils installs.

So, should I add some extra logic to the setup.py script (ie, try the dependencies myself) or is there a way to tell it "don't update the dependence if you can already import the module" in a convenient way?

There is a new option, added largely for Debian and other packagers, of python setup.py install --single-version-externally-managed. However, this doesn't add the information to an already-installed package, instead it allows package maintainers to add that egg information without otherwise effecting the layout they are using for libraries. It would almost be reasonable to add this metadata to a package that is already installed, except that I don't know how setuptools could figure out the metadata (version, distribution name) except through Debian-specific hooks. Though it is not unreasonable to write the files by hand -- I think all you need is a directory like ElementTree-VERSION.egg-info/, with one or two files in it. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org

At 02:11 PM 01/19/2006 +0100, Frédéric Gobry wrote:

Hi,

I've started using setuptools as a developer quite recently, and appreciate the extra features. I've a question though, regarding the way dependencies are resolved when installing such a package: I've written a package that uses elementtree, and would have found natural to add it in install_requires. However, I've already installed it as a debian package, and in the current state setuptools tries to reinstall over it.

On Debian-based systems, you should add these lines to ~/.pydistutils.cfg if you want to install eggs system-wide (substituting python2.4 if appropriate): [install] prefix=/usr/local [easy_install] site_dirs=/usr/local/lib/python2.3/site-packages This will ensure that easy_install does *not* try to overwrite system packages, although it may duplicate them in the interim. For more information, please see the "Custom Installation Locations" section of the EasyInstall wiki page, which describes other ways of customizing where and how packages are installed. This will of course duplicate system packages that do not carry egg metadata. If you want to make it possible to use the Debian-installed packages without duplication, you can do this by installing .egg-info files with the same base filename as the egg they would represent, placed in the site-packages directory where the package is installed. So, you might have something like "elementtree-1.0.2-py2.3.egg-info" in site-packages. The file's contents should be the package's PKG-INFO as created by the distutils. The setuptools runtime will find these files and thus know that it can access those packages as long as 'site-packages' is listed in sys.path.