On 11/26/06, Talin <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
