[Distutils] formencode as .egg in Debian ??

[Donovan Baarda]

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 <abo at minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/