On 9/10/07, Josselin Mouette <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Date: Sep 10, 2007 1:23 PM Subject: Re: [Enthought-dev] why setuptools and eggs are bad To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] https://mail.enthought.com/mailman/listinfo/enthought-dev
