Mmmm, interesting point and worth a discussion about different roles (developer, system admin, final user etc.) having different needs.
I believe distutils is used as tool primarily (setup.py bdist_rpm/msi to create installable objects, setup.py bdist_sdist to manage the source code etc.): this complicates the landscape.
Some developer has expectation (wrong IMHO) to replace a whole lot of tools with it (downloaders/installers/package managers/etc.): this is an uphill struggle against already widely deployed systems (dpkg/yum/even windows has something!).
I think Tarek did some work in the past and the result is visible in the "The Hitchhiker’s Guide to Packaging" but I've no idea where it went in the end ... only is left is a punch-in-the-eye page (http://www.python.org/doc) :D
These days I'm stuck with the old KISS approach and I write a setup.py to create "packages" and a makefile to create doc, run tests etc. I'm fairly happy with that.
On Wed 14/11/12 08:32, "Ronald Oussoren" email@example.com wrote:
I'm not convinced that distutils is untestable. A major problem with distutils is that its API is barely documented, which effectly makes all of it public API (simular to asyncore). IIRC that's the main reason
why distutils is frozen right now: with a lot of changes to distutils
started to complain that this could break there there distutils
scripts. The lack of a specification also makes testing harder, as it is unclear
what should be tested.
Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig