Re: [Distutils] formencode as .egg in Debian ??
At 11:34 AM 11/25/2005 +0000, Paul Moore wrote:
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?)
If you're not then you'll just get an error at runtime telling you the
integrity checking failed; i.e. a DistributionNotFound error.
just to get it in egg format.
More precisely, just to get something it knows for sure is an ElementTree
whose version is in the desired range.
[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,
Yep; this is why they have separate web pages. ;-)
(And also why some people call it the "eggs/easy_install/setuptools trifecta".)
and discussions are getting
confused because these are not being separated out sufficiently.
+1 :)
- what would happen if I downloaded the TurboGears egg and just put it
on sys.path - no easy_install or whatever?)
You could import stuff from it, but it might or might not work. Where it
explicitly require()'s things or tries to load a plugin, you'll get
DependencyNotFound errors.
The drop-in-and-go aspect of eggs is mainly used for application plugins in
systems like Trac, although in truth they actually use the discovery
machinery to scan their plugins directory and identify which plugins are
loadable - that is, which plugins can have all their dependencies met.
This is one reason that runtime integrity checks are important; an app can
detect that it doesn't have what's needed for a given plugin, and skip
loading it. This is also why dependency resolution needs to be able to
roll back if it fails, even for deeply-nested dependencies.
Reply to: