[Python-Dev] Distribution tools: What I would like to see

[Mike Orr]

On 11/26/06, Talin <talin at acm.org> wrote:
> I've been looking once again over the docs for distutils and setuptools,
> and thinking to myself "this seems a lot more complicated than it ought
> to be".
>
> Before I get into detail, however, I want to explain carefully the scope
> of my critique - in particular, why I am talking about setuptools on the
> python-dev list. You see, in my mind, the process of assembling,
> distributing, and downloading a package is, or at least ought to be, a
> unified process. It ought to be a fundamental part of the system, and
> not split into separate tools with separate docs that have to be
> mentally assembled in order to understand it.
>
> Moreover, setuptools is the defacto standard these days - a novice
> programmer who googles for 'python install tools' will encounter
> setuptools long before they learn about distutils; and if you read the
> various mailing lists and blogs, you'll sense a subtle aura of
> deprecation and decay that surrounds distutils.

Look at the current situation as more of an evoluntionary point than a
finished product. There's widespread support for integrating
setuptools into Python as you suggest. I've heard it discussed at
Pycon the past two years. The reason it hasn't been done yet is
technical, from what I've heard. Distutils is apparently difficult to
patch correctly and could stand a rewrite.

I'm currently studying the Pylons implementation and thus having to
learn more about entry points, resources, ini files used by eggs, etc.
 This requires studying three different pages on the
peak.telecommunity.com site -- exactly the problem you're describing.

A comprehensive third-party manual that integrates the documentation
would be a good place to start. Even the outline of such a manual
would be a good. That would give a common baseline of understanding
for package users, package developers, and core developers.  I wonder
if one of the Python books already has this written down somewhere.

>From the manual one could then distill a spec for "what's needed in a
package manager, what features a distutils upgrade would provide, and
what a package should/may contain".  That would be a basis for one or
more PEPs.

The "diff" approach is understandable at the beginning, because that's
how the developers think of it, and how most users will approach it
initially. We also needed real-world experience to see if the
setuptools approach was even feasable large-scale or whether it needed
major changes.  Now we have more experience, and more Pythoneers are
appearing who are unfamiliar with the "distutils-only" approach.  So
requests like Talin's will become more frequent.

It's such a big job and Python 2.6 is slated as "minimal features"
release, so it may be better to target this for Python 3 and backport
it if possible.

-- 
Mike Orr <sluggoster at gmail.com>