[Distutils] formencode as .egg in Debian ??

[Josselin Mouette]

Le jeudi 24 novembre 2005 à 14:13 -0500, Phillip J. Eby a écrit :
> 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.

Indeed, I arrived in the discussion a bit late, and didn't want to
intervene before having read it all. However, the implementation that
you proposed isn't clear from those messages. Putting things out of the
zip archives and having a separate file for metadata is obviously a good
thing. However, I'm still concerned about things not functioning without
this metadata, and the requirement for adding metadata in packages that
don't need it. As I still don't get the point of including this metadata
in the package, I'd have a hard time proposing other implementations.

> >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".

A sane way, first of all, means a consistent way. Having two sorts of
Debian python packages is a no-go. Therefore, if we want to switch to a
new way of distributing packages, there has to be some serious grounds
for it. Currently, the picture I have of eggs doesn't show any
advantages over the plain old distutils we are currently using.

A sane way means, when there are meaningful files that are accessed by
the interpreter in an easily understandable way, to ship them as is in a
package, not to hide them in an archive.

A sane way means not to alter functionality of other software. For
example, impacting the overall python startup time by making it unzip
all eggs is not sane, even if the impact is currently small. Modifying
the default sys.path enters in the same category.

A sane way means compliance with standards, especially the filesystem
hierarchy standard. When some people are trying to separate .py
and .pyc/.pyo files to respect it, you're asking to put them in a single
archive.

> 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.

Alright, let me try to propose something. How about defining a place in
the python distribution, say, /usr/share/python2.x/eggs (but of course
configurable when installing python), where this information should go?
An installed package would look like a directory structure of .py files
in /usr/lib/python2.x/site-packages, and a metadata file
in /usr/share/python2.x/eggs.

In fact, this approach is quite similar to the .egg-info approach, but
it would be better to put the files at the right place from the very
beginning, and, more importantly, to be able to deal with other packages
not having such .egg-info files.

> 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.

This is true. In short, my two main concerns about mozilla-related
packaging are total absence of library versioning, and the shipping of
extensions in .xpi files, which are tarballs containing information and
meta-information about the package. You can surely understand that my
concerns about eggs approach those of .xpi files.

> 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.

Sorry, but you're jumping to conclusions. Crappy packaging will be the
same for all package-based distributions.

Regards,
-- 
 .''`.           Josselin Mouette        /\./\
: :' :           josselin.mouette at ens-lyon.org
`. `'                        joss at debian.org
  `-  Debian GNU/Linux -- The power of freedom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://mail.python.org/pipermail/distutils-sig/attachments/20051124/7b1fb991/attachment.pgp