On Apr 16, 2010, at 1:35 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Lennart Regebro wrote:
...
So, with that in mind I today went on to zc.buildout, trying to port it to Python 3 by ripping out any usage of zope.testing. Also, the standard development mode for zc.buildout is that you run a dev.py script, that uses zc.buildout to build a buildout for zc.buildout. Obviously, this circularity is the same as I encountered in setuptools, and it's evil. But with zc.buildout it's easy to get rid off at least as I could use setuptools testrunner instead. But then I realize the zc.buildout needs zc.recipe.egg. And zc.recipe.egg depends on zc.buildout. Hohum, another circular depedency.
Yup. I don't even know why zc.recipe.egg is broken out from buildout at all.
When I was working on my "support system Python" branches of zc.buildout, I guessed it was because, if it is separate, then using zc.recipe.egg (which follows the standard ``recipe = `` idiom in the .cfg files) uses the same machinery that all the other recipes use. Yes, they are the same package, essentially, which is why zc.recipe.egg is part of the svn checkout of zc.buildout. I followed the same pattern in my branches for the z3c.recipe.scripts recipe. I certainly don't feel strongly about it, but it didn't seem outrageous to me.
== Suggestion 2 ==
Move the egg recipe into zc.buildout itself, and make zc.recipe.egg a dummy package that just points at zc.buildout.recipe.egg (or whatever we decide to call it). That solves that problem.
+1 from me. Graphs with cycles are pure evil.
I sure which my branches would land first, if they are ever to land. Any changes to buildout are a pain. Big changes are a big pain. Gary