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.