[Zope3-dev] setting up application dependencies

Martijn Faassen faassen at startifact.com
Sat Aug 18 13:05:08 EDT 2007


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.

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.

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.

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.

Regards,

Martijn



More information about the Zope3-dev mailing list