[Distutils] formencode as .egg in Debian ??

[Phillip J. Eby]

At 07:27 PM 11/24/2005 +0100, Josselin Mouette wrote:
>Looks like I mistakenly hoped it was possible to change things on
>technical grounds, but if you're rebutting any technical discussion as
>"irrelevant", there's probably not much to do.

On the contrary, quite useful technical discussion about how to make this 
work has taken place, including proposed changes *which I have accepted* 
and will implement.  You just haven't been participating in any of that 
discussion.


>My tone is aggressive because it's easy to feel irritated by so much
>foolishness, but on the grounds, this is still a request: please, change
>your distribution system so that it's possible to distribute your
>software in a sane way.

Please help me do that by explaining "sane way" on grounds that don't 
resort to religion.  Please explain why including a package's *own 
metadata* that the author *wished to include* is not sane.  Please explain 
why providing a consistent way (i.e. a cross-distribution, cross-platform 
way) to identify what Python libraries are installed on a system is not "sane".

Note, by the way, that those two things are the only essentials here, as 
best I can tell, and I've already stated my willingness to change *how* 
those two things get accomplished.  For clarity, I will repeat yet again, 
in yet another way:

1. Egg-based projects need to install their published metadata, in a 
well-known location relative to the installation location of their code, so 
that it can be found by searching sys.path, so that it and other projects 
can locate the metadata for currently-importable projects, *without* 
needing to first import the project's code.

2. Egg-based projects need to be able to identify whether another Python 
project package is installed and what version it is, without requiring 
modification to that other project's code or needing to import it.  (And 
this is independent of whether the depended-on project was packaged as an 
egg by its author.)

As far as I'm aware, those are the irreducible technical minimum 
requirements for making an egg-based project work.  *How* these 
requirements are met is quite flexible, as there are already three working 
layouts that achieve this.  As I said before, I'm quite willing to 
implement a fourth.  But nobody has been proposing anything that meets 
these requirements, because they're too busy trying to prove the 
requirements don't exist or are somehow not real.


>Don't become like Mozilla. You can't imagine how
>much Debian time is wasted because Mozilla developers don't care about
>the Unix way of doing things. We are receiving weekly complaints of
>users about the quality of mozilla packages, and there's nothing we can
>do for them. Don't make python-related Debian maintainership look the
>same.

Since I'm neither a Debian nor Mozilla developer, I have no way to know 
what these problems you speak of are, nor any way to tell whether the 
alleged flaws of the Mozilla packaging relate in any meaningful way to the 
alleged flaws of eggs.  It's you who's in the position of giving advocacy 
without providing any real information about the issues.

It's plain that you don't want crappy packaging.  But I've only been 
getting the barest hint of what "crappy packaging" consists of, except for 
the loud-and-clear message that it's defined as Anything But Debian.  Since 
I'm providing for users beyond Debian, that isn't useful information and 
doesn't help me investigate fixing any alleged crappiness.  It would be 
especially helpful to define what *specifically* are the problems, rather 
than continuing all this vague handwaving about elegance and sanity and the 
unspecified crappiness of all things non-Debian.  So far, every argument 
except startup performance and the length of sys.path has seemed to boil 
down to, "we don't like it so you should stop," and "we don't trust package 
developers to specify their own dependencies, so anything that allows it is 
evil".  Those aren't useful arguments, because there is nothing I can *do* 
about them.