On Sun, Jul 19, 2009 at 4:31 AM, P.J. Eby<pje@telecommunity.com> wrote:
[...] Perhaps. But it occurs to me that there is something I can do to help that in the long run. After giving it some thought today, it seems that it would be a good idea to take the "good" (i.e. relatively uncontroversial) parts of setuptools and split them out into another package, which I am tentatively naming "Discovery".
Rather than a set of executable tools, it would just be a collection of libraries to be called by package management tools, and other Python code needing to discover packages either installed on the system, on the package index, be notified when they're imported, etc. etc.
The package itself would look something like this:
discovery.resources -- basically pkg_resources under a different name
discovery.sandbox -- basically setuptools.sandbox, less distutils dependency
discovery.unpack -- setuptools.archive_util, less distutils dependency
discovery.downloads -- a hugely refactored version of parts of setuptools.package_index, redesigned for pluggable extendibility (e.g. to handle Sourceforge crap, checkouts from other revision control systems, etc.)
discovery.install -- selected subroutines from easy_install, refactored for narrow functionality and minimal coupling, combined with PEP 376 support code
discovery.importing -- basically peak.util.imports under a different name, but with a more modern/decorator-friendly API
discovery.plugins -- basically peak.util.plugins, refactored to drop dependencies on other PEAK modules
Then, easy_install could be refactored to consist mostly of calls to these other modules, along with whatever "legacy" logic needs to be retained for compatibility reasons, and setuptools proper could evolve towards just being build support, and become more pluggable generally.
It wouldn't be possible to switch setuptools to do this right away, since there would remain the problem of bootstrapping the installation of the discovery package prior to setuptools installation. But setuptools' source distribution could perhaps bundle a copy of discovery within itself, and the ez_setup.py script could perhaps then be changed to download *discovery* first -- and then ask discovery to download setuptools to a temporary location.
However, now that somebody else is effectively looking out for 0.6 maintenance, this lets me bump up the priority of working on 0.7, and has given me ideas for how to get out from under the rest of the "legacy" problems of setuptools, while also making reuse easier for competing and/or complementary projects (such as buildout, pip, etc.)
That's very interesting but you previously said that you needed time and/or someone paying you to continue the work in this area. And that you didn't have time so setuptools was just "sleeping" (that's your own word) Now, suddenly, you want to do what we planned to do in Distribute 0.7, e.g. splitting setuptools in several packages. That would be nice but I am a bit surprised, and very suspicious in fact. I am scared that at the end, you will still lock us by not blessing people to maintain yet another collection of packages you don't have time to maintain. So, I am glad that our fork made you think about your future plans, but unless you give us some guarantees, I don't see anything changing. And I'd prefer not relying on you for this because you have proven with the past year you didn't have time at all to work on the code. So are you willing to bless us maintaining/working with you with these new packages, or is that going to be a PJE-locked thing again ? If this is not stated clearly, Distribute will probably compete with your new "Discovery" packages I am afraid. Now for the packages, they all look great just a question :
discovery.unpack -- setuptools.archive_util, less distutils dependency
how this will be 'less distutils dependent' ? because I was planning to integrated setuptools.archive_util in distutils. Regards Tarek