[Grok-dev] Re: [Zope3-dev] setting up application dependencies

[Benji York]

Martijn Faassen wrote:
> Benji York wrote:
>> Darryl Cousins wrote:
>>> On Fri, 2007-08-17 at 19:24 +0200, Martijn Faassen wrote:
>>>> I think my next step is to fix some dependencies for Grok to hard
>>>> version numbers...
>>> I think that this is a good thing. I recently gave myself quite a bit
>>> grief with a careless bin/buildout which broke my application. To avoid
>>> that I need to be more specific in setup.py. (I haven't attempted it yet
>>> though).
>> Specifying versions should be done by the application (buildout for 
>> example), not setup.py.  If versions are put in setup.py they limit what 
>> others can do with the version requirements (e.g., relaxing them).
> 
> The problem with this approach is that everybody setting up an 
> application will need to know a lot about version numbers. I like reuse. 
> I don't want to expose, say, all users of Grok, to a lot of version 
> numbers they need to set.

I thin that's actually a third case.  So far we have projects, 
applications, and now "frameworks" (for lack of a better word).  Grok 
strikes me as a framework because you want to specify a known-good set 
of versions, but not in an all-in-one application distribution.

> So, in case of Grok what we don't want is that everybody needs to 
> hardcode all kinds of version numbers into their own buildout.cfg.  *the 
> same* version numbers, typically.

I'm not sure what the right approach is there, a simple versions.cfg 
that contains the suggested versions might be sufficient.

> We'd want this list of version numbers to be maintained by the Grok 
> developers instead. We could of course make our 'grokproject' tool 
> generate the hardcoded dependencies for users, but that seems rather odd 
> too. This means that if someone wants to update their grok-based 
> application to a newer version of Grok (which requires a newer version 
> of say, zope.security), they will still need to go in and edit their 
> buildout.cfg. That sounds difficult to communicate and difficult to 
> maintain.

As above, perhaps grok_versions.cfg could be one of (or the only) thing 
your users download.  That's an interesting thought, the Grok project 
can produce lots of code and distributions and when it's time for a 
release, you release the grok-1.2-versions.cfg that people can update 
their local grok-versions.cfg with.  I wonder if that model would work 
for future releases of "Zope 3".

> In case of Grok, I think we do have such a central place: grok's 
> setup.py. If we hardcode version numbers there, there's no more need for 
> people to start putting it in their buildout.cfg. It also means that if 
> people require a newer version of a library that Grok also depends on, 
> they will have to talk to the Grok developers and ask for an update. I 
> think that may have good side effects: the grok developers can then 
> first test with this updated library and after a new version of Grok is 
> released, everybody will have the benefit of the newest version of the 
> library.

That level of rigidity doesn't sound like much fun to me.
-- 
Benji York
Senior Software Engineer
Zope Corporation