Sebastien Douche writes:
On Wed, Sep 24, 2008 at 13:49, Matthias Klose <doko@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