At 07:10 PM 10/14/2006 +0200, Giovanni Bajo wrote: >Phillip J. Eby wrote: > > > Yes. "nest" will be an overall command similar to "yum" or other > > package managers of its ilk, with subcommands like "nest install" > > that will work like easy_install. > >Yes this will be great. > > > But before anybody asks, I have no clue when I'll even be able to > > start on writing nest, let alone finishing it. > >I think you could setup a wiki page with the design of the nest command. >After having discussed that, other people might be able to help with the >implementation. > > > Distutils itself is in sore need of a 3K-ing. > >Agreed, and your input as to what parts of distuils/setuptools should be >dropped would be mostly appreciated. Again, a wiki page or a PEP is in >order.
Yes, well, first I'd have to have the time for it, relative to other priorities. See above. :) I would note, however, that the thing that's probably most needed is an analysis of what features the producers of major packages with distutils extensions (Twisted, Numeric, wxPython, etc.) need in order to be able to drop their extensions. I think that maintaining API compatibility for setup scripts that don't actually extend the distutils is a reasonable possibility. Stuff that extends or monkeypatches the distutils isn't. So, we would need to get the hooks in to allow people to do the things they need without patching and subclassing. Setuptools has already shown the way forward in this respect with entry points. It's trivial to register new distutils commands, setup() arguments, and even revision control handlers for setuptools to use, and I can foresee that a distutils 3K could break down highly-coupled tools like install and its install_* subcommands to use entry points instead, so that you could e.g. add stages to a build step without needing to subclass anything. So I guess I would say that the thing that most needs to go from the distutils, is extension by subclassing -- to be replaced by extension via entry points. Note that this would also mean things like allowing compiler types to be registered via entry points, so that support for different C compilers wouldn't need to be hacked in. Thus, if people wanted to implement cross-compile support, they could do it by implementing a compiler class and registering it as an entry point. They could then distribute an egg containing that cross-compiler support class, and anyone could just install it to add a new compiler type to their distutils installation. _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
