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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Faassen wrote:
> 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?

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

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.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHmyie+gerLs4ltQ4RAq2UAJ9PztrYD3EhwlTxM2mNm10d2N3vSwCgpDfT
BwDGR9CdS317J7v/lb/YAk0=
=cEf/
-----END PGP SIGNATURE-----