[Grok-dev] Re: Martian as an external in the Grok trunk

[Jan-Wijbrand Kolman]

Martijn Faassen wrote:
> Next time I will do that, my apologies! I understand the frustration

np

> 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 
martian.

Something like:

   <a href="
       svn://svn.zope.org/repos/main/grok/martian#egg=martian-0.9.3dev">
     martian-0.9.3dev
   </a>

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.


kind regards,
jw