Hi,<br><br>I think easy_install should try to have a look at what Maven2 did. I _know_ this is never a good idea to give some java examples in a python list, but maven2 has some very interesting concepts, most of them being absolutely language agnostic. (note: Maven2, not Maven1). In fact, I think Maven2 could be implemented in any language (except that almost all examples and plugins are about java... too bad :-( ). May be there is something to learn from their experience.
<br><br>First, there is the POM. This is the equivalent of the setup.py, where we put all the description of the project. We find the authors names, the code location, the tests location, the artifacts we can create, the dependencies, etc. What is really interesting is that this description is really _only_ a description. There is absolutely no "action" (script). The POM is really conceptually close to
setup.py, without any action in it. It contains the structure of the project.<br><br>Then come the plugins. I think they are the equivalent of setuptools extensions. And really, what makes Maven so nice is really the set of plugins. Nothing else (IMHO). A few examples that are really nice: Having a fully available Eclipse project ready, with all dependencies downloaded in the local cache and included in the classpath is just one command away ("mvn eclipse"). Ok, it means a few other things, such as an artifact repository, but it's nice anyway. Testing is "mvn test", building is "mvn build", etc. (Yes I know, that's similar to some setuptools commands)
<br><br>So basically, I really think that setup.py should benefit from this experience:<br><br>- Turn setup.py into a real description-only file (no commands), or invent another file<br><br>- Have a local repository of eggs, _not_ included in the python path by default
<br><br>- Get rid of the site-package hell: find a nice way to start a python with a predefined set of eggs (yes, the equivalent of naming all the eggs in the python path, but in a more simple way, such as "python --python_path_description=myconfig", myconfig being an alias to a set of eggs)
<br><br>- Manage the dependencies by downloading the eggs in the local repository (fully independent from python itself)<br><br>- Extract everything from the core setuptools which could be in a plugin (everything which does not read the description of the project and calls the plugins)
<br><br>- Create a set of plugins to deal with most common use cases, such as packaging eggs, compiling libraries, handling special types of files etc...<br><br>- And create a nice wiki tutorial to explain how to create the best plugins you have ever dreamed of
<br><br>- Let others write the plugins for you<br><br>Actually, I believe the plugin orientation is already chosen ? ( <a href="http://mail.python.org/pipermail/distutils-sig/2007-January/007113.html">http://mail.python.org/pipermail/distutils-sig/2007-January/007113.html
</a> )<br><br>And I know that finding time is the most difficult part of it...<br><br>My 2 cents.<br><br><div><span class="gmail_quote">2007/10/3, Jim Fulton <<a href="mailto:jim@zope.com">jim@zope.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>On Oct 3, 2007, at 1:06 PM, Phillip J. Eby wrote:<br><br>> At 10:26 AM 10/3/2007 -0400, Jim Fulton wrote:<br>>> I'm a little bit worried about setuptools development cycle. We seem<br>>> to be stalled at a
0.6 pre-release that is quite stable and widely<br>>> used in production. The next feature release, 0.7, seems to<br>>> anticipate a major refactoring and major new features. I'm a bit<br>>> worried about this both from a fear of potential disruption, and a
<br>>> need for incremental feature development.<br>>><br>>> I propose that the grand re-factoring of setuptools planned for 0.7<br>>> be moved off the trunk and to a 2.x release. 0.6 should be marked
<br>>> final<br>><br>> This is coming soon, but I want to finish some ez_setup<br>> improvements first. There will be a "known issues" list to cover<br>> things like the incomplete/broken FTP support; I've given up on
<br>> trying to keep hacking it into 0.6.<br><br>I wonder what "this" you are referring to.<br><br>><br>>> Is it on the table to remove features from setuptools?<br>><br>> Yes - and most are *already* removed from the
0.7 trunk. That was<br>> the main reason for the branch.<br><br>I'm confused on a number of counts. Is the 0.7 "trunk" the same as<br>the setuptools trunk? Is there also a branch for 0.7?<br><br>Is there a list of removed features somewhere? Do we get any input?
<br><br>> Other (relatively minor) refactorings expected in 0.7 are to make<br>> URL handlers for easy_install pluggable, and to add build-time<br>> plugin options (so that people can implement custom build steps).
<br>><br>> The biggest feature additions in 0.7 would be support for<br>> uninstallation, package inspection, virtual environment management,<br>> and ability to easy_install eggs using "classic/<br>> development" (
i.e., .egg-info) installation layout.<br>><br>> Other new features planned for 0.7 include "or-ed" requirements,<br>> build/install of shared libraries, and "standard extras" (a way to<br>> specify to easy_install a set of extras that should be installed if
<br>> they are defined by the targets).<br>><br>> None of this is what I'd consider "grand" refactoring; they're all<br>> either new features or minor refactorings to make things<br>> pluggable. The most complex of them is probably the URL handler
<br>> one, and only because the existing URL handling in<br>> setuptools.package_index is so hosed.<br>><br>> Now, if you include pkg_resources in, I would rather like to<br>> refactor the way the global objects (working set and resource
<br>> manager) are handled, but I don't know how practical or even<br>> possible it is. There are other things in pkg_resources that could<br>> use refactoring, but I'm not sure I dare.<br><br>"Grand" is simply the impression I had. The list of features above
<br>is extensive though. Some of the items seem fairly big, or maybe I<br>just can't tell what they are. Do you plan to try to get all of them<br>into the next feature release? Or do you plan them a list of ideas<br>for future releases.
<br><br>Jim<br><br>--<br>Jim Fulton<br>Zope Corporation<br><br><br>_______________________________________________<br>Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br><a href="http://mail.python.org/mailman/listinfo/distutils-sig">
http://mail.python.org/mailman/listinfo/distutils-sig</a><br></blockquote></div><br><br clear="all"><br>-- <br>Laurent Ploix<br><a href="http://lauploix.blogspot.com/">http://lauploix.blogspot.com/</a>