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

[Martijn Faassen]

Jan-Wijbrand Kolman wrote:
> Another thing I found is that martian now is an external in the Grok 
> trunk. I wonder about that. Altough it might feel convenient at first 
> I'm afraid it will trips us up when releasing Grok.

Note that we do say the new Martian is required in CHANGES.txt, it's not 
that we snuck this in under the radar. :)

I don't want to *have* to release a new version of Martian whenever we 
add a new feature that Grok needs; it's nice to have the ability to add 
more than one feature before we release it, or test out a new feature 
for a while before we release it.

> Actually, having this external is I think the reason why Grok itself can 
> safely "require" martian-0.9.3 at this moment (because it will just use 
> the external as an develop-egg), but projects that are currently 
> depending on Grok-trunk will be broken as they cannot find the required 
> martian version.

They need to check out martian trunk as well and use it as a development 
egg, and list its version in [versions] (overriding the list from Grok. 
See Grok's buildout.cfg

I hate this latter requirement as I think development eggs should trump 
everything, but Jim doesn't seem to want to change this behavior:

https://bugs.launchpad.net/zc.buildout/+bug/164043

Perhaps that requirement is tripping you up?

In general, if you rely on checkout of a particular package, it may be 
you also need to depend on a checkout of certain of its dependencies. I 
think that is okay.

> My suggestion would be to:
> 
> 1) remove the external to martian
> 
> 2) introduce a dev.cfg.in file that extends from buildout.cfg. When 
> you're developing *on* Grok, you'd copy dev.cfg.in to dev.cfg, and set 
> the correct paths to the develop-eggs of e.g. martian when needed.

I'm not sure what this dev.cfg file looks like. Why should it be an .in 
file?

I think that this would trip people up. People assume that to develop a 
package you just run bin/buildout, and don't have to specify a separate 
dev.cfg to develop on a package. I don't think we want to break that 
expectation.

> I think this will force in making very conscious decissions about what 
> version of Grok depend on (in this case) what versions of martian.

I *did* make a conscious decision yesterday. I think we should be able 
to develop dependencies in parallel with Grok whenever needed. I think 
the priority is to make that development process straightforward, i.e. a 
  checkout and bin/buildout will do the job.

If you're going to rely on a development version of grok, you need to 
pay extra attention. I think that this is not too much to ask? Perhaps 
you didn't know about the [versions] way to get the new version of 
Martian and this is what blocked you?

Regards,

Martijn