On 11/25/05, Donovan Baarda <[EMAIL PROTECTED]> wrote: > On thing about this worried me; > > If TurboGears depends on an "egg'ed" ElementTree, what happens if a > system has ElementTree installed as a non-egg package? Does installing > TurboGears as an egg inside a Debian package require also installing > another ElementTree as an egg inside a Debian package? Or worse, will it > automatically download and install an egg'ed ElementTree not from a > Debian package? Will you end up with two ElementTree's installed, one > egg'ed and one not?
Yes. That's the issue I'm not keen on, and I believe your interpretation is right - TurboGears depends on ElementTree, which is fine. But *because* TurboGears is an egg [1] it *needs* an egg-ified version of ElementTree. If I have ElementTree installed already, TG will *ignore* that, and grab an extra version from the internet (at install time, presumably, assuning I'm using EasyInstall - but what if I'm not?) just to get it in egg format. This is the viral aspect of eggs - if I use an egg, I have to switch to using eggs for all its dependencies, even if I'm currently a happy user of the non-egg version of them. To me, this sucks. Sorry, Philip, I know *why* you can't introspect a non-egg ElementTree well enough to avoid this, but it still sucks. I'm also aware that in the very near future, I'll be able to just add a single empty .egg-info file to satisfy the dependency tracking, but it's still maintenance *I* have to do to satisfy TG that a package I have had for ages exists... The suckiness is certainly decreasing, but it's still there. Paul. [1] It's not exactly because TG is an egg per se, as easy_install and dependency checking is involved as well, which not all eggs have to use. I'm slowly coming to understand that eggs (and setuptools, and easy_install, which are related but subtly different items) provide a host of largely unrelated functionality, and discussions are getting confused because these are not being separated out sufficiently. I'm trying to understand all the bits, and when I do, I'm hoping to post a summary. But as an example, eggs provide: - a way to store package metadata in a runtime-introspectable way - a standard way to store and locate package data files - a package location mechanism (plugins) - a dependency management infrastructure - a way of downloading dependencies automatically - a "just drop it in" distribution format (this clashes with the dependency management stuff, and seems to be less prominent these days - what would happen if I downloaded the TurboGears egg and just put it on sys.path - no easy_install or whatever?) plus many others, I think. These are *not* the same. Some (package data, plugins) have been invented before, probably many times, and eggs just provide a standardised drop-in approach. Some are relatively non-contentious useful tools. And some are much more contentious. I've more to say on this, but I'll wait until I've done my research.