On Fri, 2005-11-25 at 01:33 -0500, Phillip J. Eby wrote: [... long informative explanation of egg...]
So it sounds like egg duplicates much of the functionality of the Debian Package manager, but also extends it slightly in python-specific ways. I can under stand the Debian packagers asking themselves; do we just wrap an egg in a Debian package and accept the duplicated functionality, or do we unwrap the egg, add the missing functionality some other way, and create a clean Debian package without the duplicated functionality? The biggest risk of just wrapping the duplicated functionality is; are there incompatibilities or policy violations in the egg way of doing things? In particular, will an egg wrapped inside a Debian package magically install other bits of software not from Debian packages? Will it install them in the correct places? > While I don't advocate changing all Debian Python packages to add this > metadata, I do suggest it's a practical way to deal with certain dependency > issues. For example, TurboGears depends on ElementTree, which is not > packaged as an egg by its author. (I think that Kid, which is also an > egg-packaged TurboGears dependency, may depend on ElementTree as > well.) Anyway, the quickest way to get all this stuff working without a > lot of hacks to the dependency metadata would be to install an .egg-info > marker with the ElementTree package, so that the egg tools and runtime on > any user's machine will simply know what version of ElementTree is present, > and be happy. 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? > I know - you can think of other ways to deal with this. However, most of > the ways that have been suggested to date fail in the use case where a user > has been using the Debian package, and Kevin moves to requiring a new > version of ElementTree or some other dependency, perhaps a new SVN revision > that hasn't been released -- foobar-1.3.dev-r4262, let's say. (Setuptools > users can have their builds tagged with a repository revision > number.) This release of foobar isn't going to be in Debian unless you're > tracking subversion revisions of experimental projects daily - and maybe > you are, I don't know. The point is that when the Debian package no longer > satisfies the dependency, the egg tools move smoothly to downloading and > installing wherever the user has configured their development environment > to install it, say their ~/pydev directory. So now we've segued smoothly > into "multiple versions" being installed, but the "system version" is still > intact. Debian has versioned dependencies. If a package depends on a particular version of another package that doesn't exist yet, you can't install it; full stop. If you want to package something that depends on a SVN revision of some dependency, then you need to package that SVN version. This is part of Debian's quality control. Debian Packages are only installable if their dependencies are met, and incompatible combinations of packages cannot be installed at all. This enforces packagers to produce a distribution of packaged versions of everything that will work together. It sounds like egg's provide python specific package management focused on development. All that "automatically pull in all the eggs of versions **I** want" allows developers to specify bleeding edge dependencies and not have to worry about dependencies of other things on the system. Debian packages are more focused on stabilising for distribution releases. It encourages/forces you to agree on particular versions of everything for the whole system in a very controlled manner. I think they a both important. If I was using eggs, I'm not sure I'd want them to be packaged as anything other than an egg until I was ready to release, and then I'd want it **not** packaged as an egg, as a "proof of it's release readiness". It's perhaps unfortunate that egg's bundle package management with generic meta-data management. I know that package management uses meta-data, but if it was implemented as one wrapped around the other, you could "peel the package management layer off", leaving the metadata management there, and you could produce clean deb's using only Debian package management, but with the egg meta-data management still in place. If you ever want to install stuff that is not in a Debian package, it should be installed outside of the package-managed directories. On Debian, this usually means anywhere in /home or /usr/local. I'd be installing eggs in /usr/local until they were ready to be packaged as a proper Debian package. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]