[Distutils] Annoucing distribute project

[Matthias Klose]

Sebastien Douche writes:
> On Wed, Sep 24, 2008 at 13:49, Matthias Klose <doko at cs.tu-berlin.de> wrote:
> > announcing a fork without any objective? what is this fork about?
> 
> Python community *must* have a robust, stable and well featured
> infrastructure like Cpan, Gem or Apt. The actual situation is insane:
> 
> - Setuptools is not on Python core
> - single point failure infrastructure (pypi.p.o)
> - not compatible with Hg / Bzr / Git out of the box
> - missing some features
> 
> 
> As far I see, the goal is to speed up the development of a great tool,
> not just a fork for fun :).
> 
> 
> PS: within 1 month, Ubuntu 8.10 & Debian 4.2 are out (default svn :
> 1.5). It's not acceptable to say "use trunk version, stupid!"

For distributors like Debian, Fedora or Ubuntu, setuptools is still in
a state where it's better ignored than used. It's fine to ship it, but
using it in the distribution is a pain. Until today setuptools doesn't
have the features needed by os distributors, and things like
--single-version-externally-managed were only reluctantly added. Some
things to change:

 - os distributors usually try to minimize the versions they include,
   trying to just ship one version.  This single version is installed
   with --single-version-externally-managed, so that it can be
   imported without any pkg_resouces magic and fiddling with pth
   files. Unfortunately then it is not possible to use/import another
   version using pkg_resources. As discussed at PyCon such a setup is
   very common for os distributors. How will the fork handle such
   setups, and maybe incompatible changes?

 - setuptools has the narrow minded view of a python package being
   contained in a single directory, which doesn't fit well when you
   do have common locations for include or doc files. Does the fork
   accept patches to change such limitations and allowing FHS
   compliant packages?

A branch with patches for the stable setuptools branch sounds fine. It
makes it more easy to apply these fixes to the setuptools package as
distributed by Debian and Ubuntu. But I doubt it will be good enough
with the "compatibility approach" because changes like the ones
mentioned above still seem to be left to the setuptools maintainer.

Plus the name of the fork suggests that the all-coupled/all-integrated
approach will live on, and distribute will remain a monolithic chunk
of code.

  Matthias