[Distutils] setuptools development cycle

[Jim Fulton]

On Oct 3, 2007, at 1:06 PM, Phillip J. Eby wrote:

> 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.

I wonder what "this" you are referring to.

>
>>  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.

I'm confused on a number of counts.  Is the 0.7 "trunk" the same as  
the setuptools trunk? Is there also a branch for 0.7?

Is there a list of removed features somewhere? Do we get any input?

> 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.

"Grand" is simply the impression I had.  The list of features  above  
is extensive though. Some of the items seem fairly big, or maybe I  
just can't tell what they are. Do you plan to try to get all of them  
into the next feature release? Or do you plan them a list of ideas  
for future releases.

Jim

--
Jim Fulton
Zope Corporation