Re: [Distutils] formencode as .egg in Debian ??
On 11/25/05, Donovan Baarda <abo@minkirri.apana.org.au> 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.
Reply to: