[Distutils] formencode as .egg in Debian ??

["Martin v. Löwis"]

Phillip J. Eby wrote:
> I was referring to how the distribution is *installed*.  You don't use 
> things directly from a deb file, they have to be installed on the 
> system.  When you install an egg, you must use one of the three forms, 
> or the system as a whole will not function.

That depends on whether the "system" (pkg_resources, I assume) is used
at all. If the project is just a Python library, you can install it
as a Python package in site-python, not as an egg.

> Eggs that depend on the egg 
> will not be able to find it, nor use any plugins it contains.

Not sure what an egg plugin is, so I cannot comment on that.
As for other eggs finding the one: In Debian, there normally shouldn't
be any need to, since there will be also a Debian package providing
the other project, and then a plain "import" will be sufficient to
find the Python package.

Of course, any usage of the pkg_resource API would break. One way
to deal with that is to encourage upstream authors to have a fallback
mode where they can work without pkg_resource; another is to provide
a fallback implementation of pkg_resource.

> So, when I say it is a contradiction in terms to install an egg in a 
> non-egg form, I mean that it is nonsensical to say that you have 
> installed it, because it will be unusable (by other eggs), nonfunctional 
> (by itself), or both.

That makes me not like the egg infrastructure: too many subtle
dependencies, and you are too much forced into using the structures
that the setuptools authors came up with.

Of course, the pragmatic view is just to bite the bitter pill (is
this the idiom?) and find some strategy that makes pkg_resource
work, without any of the drawbacks of setuptools.

>> I would expect that you can "unegg" a project.
> 
> 
> For projects that make use of eggs, you expect wrong.  Try it with 
> setuptools, and you will find that it is unable to even run its own 
> tests, because the "test" command is registered via an entry point.  

I would have to rewrite the code, of course. I do all registration
that needs to be done in __init__.py

> Entry points are just one kind of project metadata that can be 
> registered; other projects like Trac and SQLObject have their own kinds 
> of metadata as well.  None of this metadata is accessible without the 
> EGG-INFO or .egg-info directory; removing it is like removing the 
> JavaBean metadata or the deployment descriptors from Java jars, 
> rendering the jar useless in many contexts, despite the fact that all 
> the "code" remains.

Sure, *just* removing it would be wrong. I have to replace it with
Python code.

> The only projects that can be "unegged", then, are ones that no egg 
> project depends on, and which do not themselves depend on any eggs.  The 
> number of projects that are not depended on by other projects will be 
> smaller and smaller over time, as will the number that do not depend on 
> other eggs.

Define "depends on". If this is "imports", I don't see a problem with
unegging the package. If the dependent package is installed, the import
statement will just succeed right away.

> In essence, trying to work around the absence of egg metadata is a 
> bottomless pit, because over time there will be an ever-increasing 
> amount of functionality in the field that is based on the use of metadata.

That is really sad.

>> I would add the complaint:
>> - it increases sys.path for no good reason.
> 
> 
> It is only true that it increases the length in the case of the two .egg 
> forms, not the .egg-info form.

Ok, then I think this is what Debian should use.

> The "no good reason" part is an interesting opinion, although in my view 
> it is rather narrow-minded.  Being able to support multi-version 
> importing is a very good reason indeed, as is avoiding the need for a 
> platform-specific package management tool in order to manage Python 
> projects.

I don't see why multi-version support necessarily requires to
increase sys.path. In the case of eggs, version dependencies are
expressed explicitly in the code (through require() calls), so
that essentially replace the standard Python import search algorithm.
Because of that, you could have a default version inside site-packages,
and additional versions elsewhere, only found when require() is
called.

Regards,
Martin