[Grok-dev] Re: Martian as an external in the Grok trunk
janwijbrand at gmail.com
Thu Jan 24 14:42:17 EST 2008
Martijn Faassen wrote:
> Next time I will do that, my apologies! I understand the frustration
> it's just hard to juggle all these configurations.
Yes, it is... :-)
>> However, I still think having martian as an external in Grok could
>> potentially hide the requirement for having martian of a certain
>> version *released* when there's a Grok *release* being made.
> That's true. I think special attention needs to be taken when releasing.
> Reading CHANGES.txt carefully before release should help, I think. Of
> course we'd typically we releasing martian before we release grok
> anyway, if necessary.
Hmmm, I'm not completely satisfied with this answer.
I think it is weird to introduce an svn:external to martian, in order to
have a predictable path to it in the develop directive in the
buildout.cfg. I mean, I cannot easily imagine doing the same thing if it
were, say, zope.interface that had an unreleased feature that we'd like
to rely on.
Now I realize grok and martian have a special kind of relationship, but
they were split-off in separate projects to give each their own
life-cycle. In a way, they're tied back to each other again.
I'd also like to stress again that it makes pulling a grok release a bit
harder now, especially if it comes to creating a tag and/or a branch for
this released version.
Besides the regular release-procedure steps (that philikon put together
and work great so far) in order to release grok, we now also need to
adjust the buildout.cfg *and* remove the the svn:external after creating
the tag (or branch), as it makes no sense at all to have a develop
directive pointing to the *trunk* of martian on this tag (or branch).
Now, I probably should provide an alternative solution at this point.
I'm, not sure I have one, but I can try to explain what we (me and my
colleagues at work) do in the case where an 'application' relies on
unreleased features in another 'library' that is being developed.
When developing on two projects at the same time, we create a dev.cfg
file extending the project's buildout.cfg. It overrides the develop
directive, pointing to not only the package we're working *in* and *on*,
but also to the checkout of the other project. This dev.cfg is not
something that is checked in (forget my initial comment about a
dev.cfg.in - that comment didn't make any sense in this context).
So, whenever you need to run buildout again during the development cycle
where two projects are evolving at the same time, you do...
$ ./bin/buildout -c dev.cfg
...and your buildout will have two develop eggs. After finishing this
particular development cycle I think you can do one of two things:
1) release the 'library' now containing new features that your
'application' relies on or,
2) provide buildout with enough information to be able to obtain an egg
for the current "snapshot" of the supporting 'library' whenever buildout
is run withoud the -c option for the 'application'. In this case, one
could imagine putting a link to the martian trunk on the pypi page of
You made clear already that releasing martian is not an option at this
moment, so I can imagine something like the second solution. It's
essentially what I do at work do so far.
Even if the solution is not perfect (and in fact, if others have
suggestions I'd very much like to hear it), but at least we don't need
an svn:external to a supporting library nor to have a buildout.cfg with
a develop directive that points to anything but the project itself.
More information about the Grok-dev