[Python-Dev] "setuptools has divided the Python community"

Thu Mar 26 20:50:58 CET 2009

On Wed, Mar 25, 2009 at 8:36 AM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
> On Wed, Mar 25, 2009 at 1:25 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> Paul Moore <p.f.moore <at> gmail.com> writes:
>>>
>>> 3. Setuptools, unfortunately, has divided the Python distribution
>>> community quite badly.
>>
>> Wait a little bit, and it's gonna be even worse, now that buildout and pip seem
>> to become popular. For example, the TurboGears people are considering switching
>> from setuptools to pip...
>>
>> Combined with
>> the current trend that everything must be exploded into lots of interdependent
>> but separately packaged libraries (the paste/pylons syndrome... try pulling
>> something like TurboGears2 and see how many third-party packages it installs), I
>> fear this is going to generate a very painful user/developer experience :-(
>>
>
> I think we are in a point in Python development where we need to clearly define
> how dependencies work.

+1

> And this has to be defined in Python (in Distutils)
> for the sake of standardization.
>

Well, I mentionned I did it using apt + insinstall support ... but I'd
love to have all these things in Python ... with or without relying on
OS-specific infrastructure for managing pkgs, deps and so on ... It is
possible to have two approaches :

- a thin layer on top of OS-specific (dpkg + apt, rpm + yum,
wininstall, mac os ... ) pkg managers so that distutils be able to use
them directly whille still keeping a single model from the end-user
perspective ... At least there exists some kind of python-debian pkg
...

{{{
$ apt-cache show python-debian
Package: python-debian
Priority: optional
Section: universe/devel
Installed-Size: 268
Maintainer: Ubuntu MOTU Developers <ubuntu-motu at lists.ubuntu.com>
Original-Maintainer: Debian python-debian Maintainers
<pkg-python-debian-maint at lists.alioth.debian.org>
Architecture: all
Version: 0.1.9
[...]
Depends: python (>= 2.4), python-support (>= 0.7.1)
Recommends: python-apt
[...]
Size: 43662
[...]
Description: python modules to work with Debian-related data formats
 This package provides python modules that abstract many formats of Debian
 related files. Currently handled are:
 * Debtags information (debian_bundle.debtags module)
 * debian/changelog (debian_bundle.changelog module)
 * Packages files, pdiffs (debian_bundle.debian_support module)
 * Control files of single or multple RFC822-style paragraphs, e.g
   debian/control, .changes, .dsc, Packages, Sources, Release, etc.
   (debian_bundle.deb822 module)
 * Raw .deb and .ar files, with (read-only) access to contained
   files and meta-information
[...]
}}}

Since there are a lot such systems (at least for Linux ...) ... this
could also mean that it could be very complex to handle all this
diversity ... However there are a few which are highly influential ...
but this is certainly a concern ...

- A fully fledged implementation from scratch so that distutils be in
charge, all apps be consistent with Py-std ... and users have
potentially two pkg systems (.. the built-in and the Py-specific ;) ;
and I say potentially since it's quite sudden so far and perhaps there
is a way to smoothly integrate both systems (which are potentially
many of them ;)

> I think the Language Summit tomorrow is a good place to discuss about
> these problems,

Hope it be available (recorded ?) some day so as to hear some opinions ... ;)

> and to make sure pip, setuptools and zc.buildout rely on the same
> standards and pieces.
>

Oh yes !
+1

> PEP 376 is my first attempt to make it happen, and my goal is to see another
> pre-PEP coming out of thea language summit, adressing the dependencies problem.
>

;)

> I can't hear that setuptools has divided the Python community.

Said like this ... some might think that setuptools is responsible for
someone else's choices and actions ... and I dont think so ...

> It has provided
> solutions to real problems we had in web development. It's unperfect,
> and it has to be
> fixed and integrated into Python. But it should not be done outside Python imho.
>

I mostly agree with all this, but I would like to know something ...
in case a single pkg management sys be ready for Py (... I mean
integrated into Py ...) and so on ... Why will we need distutils
comands like :

bdist_msi
bdist_wininst
bdist_rpm
<... more «non-standard» candidates like py2exe, stdeb, ...>

? Will all this still be necessary and maintained ? As long as
installing /uninstalling them be handled correctly in built-in as well
as Py systems (considering the duplicate «package repositories» ...)
... I think this could be fine ... but details are details ... ;)

> If you had worked with Zope 5 years ago, you would understand what
> setuptools and
> zc.buildout brought to these communities. And today's experience is a
> whole less painful trust me.
>

Yes ... setuptools has undoubtedly its own value ... :o)

> But I agree that the sizes of the packages are too small now, and it has gone
> to far. Installing a web app like Plone is scary (+100 packages)
>
> But this is the responsability of Zope, TG, etc to distribute their packages in
> bigger pieces I guess.
>

I do think so ... The same happens with Trac plugins. In case of
browsing the archive of trac-users mailing list anyone can realize
that there are many related plugins people'd like to install at once
to get the whole functionality. Nowadays in some cases they have to
install ... *a loooot* and then configure ... *a loooot* in order to
get the whole thing working out ... and there are tiny but useful
plugins ... Besides further contributions seldom end-up with potential
interoperability issues and related features might not be tested as a
whole ...

And things that should be in core (e.g. AccountManager plugin ...
since it seems there is no way to log out if it's not installed ... ;)
are not still there (... took some time until trac-devs decided to
incorporate it during PyCon'09 sprint ... ;)

But this unification is definitely up to the plugin & framew devs ... IMO

--
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/