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 _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
