Ported directives to Martian's new directive implementation. As a result, many helper functions that were available from were removed. The functionality is mostly available from the directives themselves now. Refactored class grokkers to make use of Martian's new declarative way for retrieving directive data from classes, and Martian's new declarative way to write grokkers. See the (
rm -rf PasteDeploy-1.3.1-py2.4.egg rm -rf Routes-1.7.3-py2.4.egg rm -rf WebHelpers-0.3.2-py2.4.egg rm -rf Beaker-0.9.5-py2.4.egg rm -rf FormEncode-0.7.1-py2.4.egg rm -rf decorator-2.2.0-py2.4.egg rm -rf nose-0.10.3-py2.4.egg rm -rf Mako-0.1.8-py2.4.egg rm -rf WebOb-0.9.2-py2.4.egg rm -rf simplejson-1.7.1-py2.4.egg rm -rf Babel-0.9.2-py2.4.egg rm -rf Pylons-0.9.6.2-py2.4.egg rm -rf Genshi-0.5-py2.4-macosx-10.5-i386.egg rm -rf SQLAlchemy-0.5.0beta1-py2.4.egg rm -rf ToscaWidgets-0.9.2-py2.4.egg rm -rf TurboGears2.egg-link rm -rf Paver-0.8.1-py2.4.egg
/Users/kteague/buildouts/shared/eggs/Routes-1.7.3-py2.4.egg /Users/kteague/buildouts/shared/eggs/Routes-1.9-py2.4.egg
Neither of these are active on your Python path, but you can pop them onto your sys.path and import the version you require as desired. This approach means that your application declares what versions of which packages it wants to use
This is similar to the approach that Ruby Gems takes. I'm not sure if it's better than the buildout approach, since this approach embeds your library dependency information in the source code instead of having that information available in an easily parsed buildout.cfg or setup.py file.