[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Distutils] formencode as .egg in Debian ??



At 01:39 PM 11/25/2005 +0000, Paul Moore wrote:
On 11/25/05, Donovan Baarda <abo@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.



Reply to: