Re: Python Egg Guidelines across distros
On 9/10/07, Josselin Mouette <joss@debian.org> wrote:
> Le vendredi 07 septembre 2007 à 22:53 +0200, Stefano Canepa a écrit :
> > do you mean using setuptools upstream is bad for the resulting debian
> > package? Could you explain why?
>
> Setuptools was designed by developers, for developers, and not much for
> users. More specifically, it was designed for developers working on a
> certain operating system which doesn't have a decent packaging
> infrastructure.
[....]
I am forwarding a relevant opinion from a mayavi2, traits mailinglist
(I am doing the packaging of mayavi2 and traits for Debian).
Ondrej
---------- Forwarded message ----------
From: Gael Varoquaux <gael.varoquaux@normalesup.org>
Date: Sep 10, 2007 1:23 PM
Subject: Re: [Enthought-dev] why setuptools and eggs are bad
To: enthought-dev@mail.enthought.com
On Mon, Sep 10, 2007 at 12:26:18PM +0200, Ondrej Certik wrote:
> this debate on debian-python mailinglist could be interesting for you
> (see also all related messages):
> http://people.debian.org/~terpstra/message/20070910.084442.11816b2b.en.html
Interesting. These guys have been stumbling on the same issues than us
for packaging.
To sum up, the problem is that setup tools is not designed to interact
with the outside world. It does not provide an api for listing
dependencies, does all kind of magic during the install, and insists for
doing everything itself, and not exposing the info it has to the external
world.
This is bad because the way it is doing things may not fit with a certain
platform's need and existing packaging system. Actually setuptools is
designed with Windows in mind.
Now my work around for packaging ETS has been the coarse-grained source
tarballs: I have a script that inspects the dependencies of an egg,
downloads them (this script was an absolute pain to write, and is
fragile, as setuptools does not expose a proper API for all these things,
and there is a lot of guess work to do). It can be enhanced to build a
partial dependency tree (why the hell is it something that we should do,
setuptools must be doing this, I want this info exposed !). Once the
packages downloaded, the dependency tree built, tarballs can be created
with the relevant info, and I can group the packages, in the case of the
ETS. This script should be enhanced to gather the info to make a real
.deb, and expose the relevant info (package description, version, ...) to
another packaging system.
I also totally strip the Python source from anything relevant to
setuptools, this way I am sure there is not setuptools introduced magic
in them. Setuptools is only a build requirement.
Incidentally, this is somewhat similar to Andrew Straw's stdeb, expect it
focuses on downloading and grouping packages.
If you want to forward this mail to the relevant mailing list
(debian-python, setuptools) go for it. I am happy discussing my
conclusions and providing my hackish script to who ever wants it. I wont
go myself on these lists because I don't like complaining without
providing a solution, and I don't have time to look at the problem more
in details. There is a problem, though, and setuptools guys should be
aware of it and try to address it quickly, elsewhere they will have the
community of packagers more and more angry at them. One of the
conclusions of the debian-python thread Ondrej points to is that upstream
maintainers should be discouraged to use setuptools.
Gaël
_______________________________________________
Enthought-dev mailing list
Enthought-dev@mail.enthought.com
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply to: