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

["Martin v. Löwis" <martin@v.loewis.de>]

Phillip J. Eby wrote:
> > > > Debian should provide the packages, but not as eggs.
> > >
> > >
> > > For packages that only operate as eggs, and/or require their 
> > > dependencies as eggs, you are stating a contradiction in terms.  Eggs 
> > > are not merely a distribution format, any more than Java .jar files are.
> >
> >
> > So I should say
> >
> > "Debian should not provide eggs, period", since what Debian provides
> > are packages, and eggs are not?
>
>
> I don't understand you.

This is getting difficult: I don't actually know what "a contradiction
in terms" is. You seemed to be saying that eggs are not a distribution
format. If so, Debian should not distribute them. If eggs are,
in fact, a distribution format: what is the contradiction then?
I would still claim that Debian should not distribute them, but
instead distribute policy-conforming Debian packages instead.

> > I didn't say the egg system in inoperational. I said that distutils
> > setup is not operational for, for example, FormEncode: this uses
> > another packaging library in setup.py, not distutils setup.
>
>
> I still don't understand you.  If a package subclasses a distutils 
> command, is it no longer a distutils setup?

It is not a distutils setup because it does not invoke
distutils.core.setup.

Also, if it did so, and changed the install command to do something
inherently different (like installing into a different target directory
without the user asking for it), it is not a distutils setup anymore.

> What if it bundles a 
> library module that includes a subclass of a distutils command?  Where, 
> precisely, do you draw the line between a "distutils setup" and 
> something else?

Extending distutils is fine. An extension is a feature that, if not
invoked, has no effect. easy_setup changes install in a way that
has an effect.

> *Many* packages subclass distutils commands or use 
> unusual arguments to the distutils setup() that cause things to be 
> installed in unusual ways.

Yes, but they preserve the default behaviour: packages get installed
into subdirectories of site-packages if you invoke the install
command.

> > This is not the same. A java .jar file is deployed by putting it on 
> > disk. For an egg, an (apparently undocumented)
>
>
> An egg must be on sys.path, if you want to use it without explicitly 
> using the egg runtime.  See "The Quick Guide To Python Eggs", in 
> particular this passage from 
> http://peak.telecommunity.com/DevCenter/PythonEggs#using-eggs :
>
>    "If you have a pure-Python egg that doesn't use any in-package data 
> files, and you don't mind manually placing it on sys.path or PYTHONPATH, 
> you can use the egg without installing setuptools."

Right. However, easy_setup apparently edits a .pth file to achieve
this effect. This is different from jarfiles, where the end-user is
expected to put it on sys.path.

While this would be possible to do for egg files as well (ie
just drop it somewhere, and let the user edit PYTHONPATH), it violates
Debian policy to do so: the packages should be immediately usable
after the Debian package is installed.

> Nothing except performance considerations prevents you having a separate 
> .pth file for each and every egg

That is not true. Usability also suffers if sys.path becomes long.

> just as nothing prevents distutils 
> packages from being installed as directory+.pth today.  Does Debian 
> currently reject packages that use the extra_path argument to setup(), 
> like Numeric?

No. The policy states "Install your modules into 
/usr/lib/pythonX.Y/site-packages/". This is somewhat imprecise,
and it is not clear (to me) whether the python-numeric violates
that policy or not.

>> but in a way unfriendly to dpkg
> I don't understand you here.  Are you saying that it's not possible for 
> dpkg to do a post-install or uninstall operation like adding or removing 
> a line from a file?

That is certainly possible - but currently, each maintainer would have
to come up with his own solution. This is more tedious to do than it
could be.

> Here are the steps to create a "single-version" egg:
>
> 1. Build the egg
> ...

This is still tedious to do, but certainly fits with Debian conventions
(policy or not) better than any other approach.

> Of course, this creates additional work for package maintainers that 
> wouldn't be present with setuptools' normal .egg file/directory 
> distributions, and my assumption was that the maintainers would prefer 
> to be able to ignore such issues and get the benefit of dependencies 
> defined by the upstream developers.  Eggs keep each project in its own 
> little bubble, where it can't overwrite anything else and can be 
> uninstalled without removing any overlapping parts.

I don't see how the maintainer could use the dependency information
in the egg files. Debian policy is that the .deb files need to
define proper dependencies, so the maintainer has to lookup
and edit the dependency information *anyway*. Using the egg
package name is of limited, help, either, because Debian policy
mandates a certain naming scheme for packages, giving the
FormEncode package a name of python2.4-formencode.

Regards,
Martin