[Distutils] setuptools development cycle

[Phillip J. Eby]

At 10:26 AM 10/3/2007 -0400, Jim Fulton wrote:
>I'm a little bit worried about setuptools development cycle.  We seem
>to be stalled at a 0.6 pre-release that is quite stable and widely
>used in production.  The next feature release, 0.7, seems to
>anticipate a major refactoring and major new features.  I'm a bit
>worried about this both from a fear of potential disruption, and a
>need for incremental feature development.
>
>I propose that the grand re-factoring of setuptools planned for 0.7
>be moved off the trunk and to a 2.x release.  0.6 should be marked
>final.

This is coming soon, but I want to finish some ez_setup improvements 
first.  There will be a "known issues" list to cover things like the 
incomplete/broken FTP support; I've given up on trying to keep 
hacking it into 0.6.


>  Is it on the table to remove features from setuptools?

Yes - and most are *already* removed from the 0.7 trunk.  That was 
the main reason for the branch.

Other (relatively minor) refactorings expected in 0.7 are to make URL 
handlers for easy_install pluggable, and to add build-time plugin 
options (so that people can implement custom build steps).

The biggest feature additions in 0.7 would be support for 
uninstallation, package inspection, virtual environment management, 
and ability to easy_install eggs using "classic/development" (i.e., 
.egg-info) installation layout.

Other new features planned for 0.7 include "or-ed" requirements, 
build/install of shared libraries, and "standard extras" (a way to 
specify to easy_install a set of extras that should be installed if 
they are defined by the targets).

None of this is what I'd consider "grand" refactoring; they're all 
either new features or minor refactorings to make things 
pluggable.  The most complex of them is probably the URL handler one, 
and only because the existing URL handling in 
setuptools.package_index is so hosed.

Now, if you include pkg_resources in, I would rather like to refactor 
the way the global objects (working set and resource manager) are 
handled, but I don't know how practical or even possible it 
is.  There are other things in pkg_resources that could use 
refactoring, but I'm not sure I dare.