Re: [Distutils] formencode as .egg in Debian ??
Alle 12:34, venerdì 25 novembre 2005, Paul Moore ha scritto:
> 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.
Please read
http://mail.python.org/pipermail/distutils-sig/2005-November/005520.html
http://mail.python.org/pipermail/distutils-sig/2005-November/005521.html
Can my proposal resolve the "suckiness".
> 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
More hooks could be provided (apart from the one thtat just checks for
dependencies) to allow distributors redefine where things are installed and
how to find them.
This way the logical egg parts (code/metadata/plugins) will become a "guide"
distributors will use to put things in the "Right Place (tm)".
Accepting my proposal will make the actual setuptools one of the
implementatios of the "egg concept" and the mother of all other
implementations (in the some way distutils is the mother of setuptools).
A distributor could provide a custom setuptools implementation that is just
the original setuptools + some code (plugins to setuptools itself?, hooks
anyway) that both checks for dependencies/metadata/plugins/... and acts in
response to checks in a custom way.
This way the egg concept will become othogonal(meaning unrelated) to the egg
format.
Anyway the custom setuptools will be able to fallback to the original
setutools way of handling eggs (the only difference is that it will install
things into user home or /usr/local).
> 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.
> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
Vincenzo
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
Reply to: