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

Martijn Faassen faassen at startifact.com
Sat Jan 26 16:44:07 EST 2008

Tres Seaver wrote:
> FWIW, I would prefer that the checkout of grok *not* include the
> dependencies:  if a particular developer is testing a newer version of a
> dependency, then s/he should be comfortable with getting that version
> installed (e.g., via 'setup.py develop' in a checkout).

The Grok trunk won't *work* without the trunk version of Martian. What 
are you suggesting as an alternative? Have people check out and install 
Grok trunk and discover test failures? Do we then say: "we're sorry, in 
order to develop Grok, you also need to check out a development version 
of Martian. The installation system of the Grok trunk currently just 
don't work and here are the manual instructions."

> Shipping unreleased dependencies in a checkout encourages lazy mistakes
> at release time, where they are catastropyic, to save effort for the
> person who is already offroading, and should thus be capabal of fixing
> whatever issues crop up.

I think it's an exaggeration to call mistakes at release time 
catastrophic; a botched release is unfortunate.

I consider release time a good time to go through the dependencies and 
see whether any updates need to be released of dependencies in order to 
make the release work. This can be done by going through CHANGES.txt, 
where such updated requirements will be marked, and by looking at 
setup.py. Clearly though I hope we can release a new version of Martian 
before release time.

I'm not sure why you describe me and those who paired with me at the 
sprint as people "offroading". We're talking about developing Grok. 
Sometimes the development of Grok needs some improvements or changes in 
its dependencies. Sometimes a period of parallel development cannot be 
easily avoided.

I can see a better way to avoid affecting the trunk. What I think we 
should have done is branched Martian when we realized it needed 
incompatible changes, and put in an external in *our* branch to depend 
on that. Then when we're happy to merge the branch, we could have first 
merged Martian, release a new version, and then merge things to the Grok 
trunk and rely on the newer version. Perhaps this is a good guideline 
for developing dependencies in general? (managing dependencies is and 
will remain hard though; I think we cannot avoid *all* pain :)



More information about the Grok-dev mailing list