[Distutils] formencode as .egg in Debian ??

[Phillip J. Eby]

At 01:39 PM 11/25/2005 +0000, Paul Moore wrote:
>On 11/25/05, Donovan Baarda <abo at minkirri.apana.org.au> wrote:
> > Sorry... that's what I meant; don't deb an egg... install it as an egg,
> > outside of the Debian package management system. As an egg, it is under
> > development and not ready for release as a deb. When the software is
> > ready for release, strip the egg package management layer and create a
> > proper deb out of it.
>
>Again, this is something I picked up from previous discussions of this
>nature, but you can't "strip the egg package management layer" without
>also stripping out the other features of eggs, such as plugin support,
>metadata introspection, etc, which are useful whether or not you care
>about package management.
>
>So, as a package developer, if I want to use egg metadata or plugin
>support, I have to buy into the whole egg experience, including the
>installation stuff.

Actually, I thought you wanted eggs to be wrapped in system packages, so 
that you don't have to use the "installation stuff".  That is, after all, 
what this extended thread is about: providing system packages of egg 
projects, and allowing egg dependencies to be met by system packages.


>I'd argue that the different features should be separated, so that
>people can choose the ones they want to use (and as a consequence, the
>"egg package management layer" could be stripped out independently).
>But that doesn't seem to be the direction the development is going.
>
>Apologies if this is incorrect. I'm still researching...

The issue is integrity checking.  Python imports as an integrity check are 
not safe in the general case, *especially* in Python 2.3, where a failed 
nested import results in an importable but broken module.  Integrity checks 
are also essential for plugin support, since many plugins will probably 
*not* be system-managed, so the app has to be able to tell if it can load 
the plugin or not.  A plugin, however, may have dependencies that can be 
satisfied by system packages, like if the plugin uses ReportLab or 
something to add PDF support to an application's export menu.

That's why you can't really just "peel off" the egg shell here; the whole 
stack was designed to support quality plugin systems for Python apps, 
similar to the  Eclipse or OSGi systems in the Java world.