[Grok-dev] Re: zc.sourcefactory

[Philipp von Weitershausen]

On 4 Sep 2007, at 01:26 , Tres Seaver wrote:
> Philipp von Weitershausen wrote:
>> Sebastian Ware wrote:
>>> Shouldn't dependencies be put in setup.py like this (?):
>>>
>>>       install_requires=['setuptools',
>>>                         'grok',
>>>                         'zc.catalog==1.1.1',
>>>                         'hurry.query',
>>>                         'hurry.workflow',
>>>                         # Add extra requirements here
>>>                         ],
>>
>> Yes, dependencies should be put in there, but not specific versions.
>
> I think there are cases for pinning specific versions:  removing
> "degrees of freedom" here can be a sanity saver.  As I noted in  
> another
> thread, I think that we end up solving the "known good working set"
> problem by creating an egg whose only job is to pin down the  
> versions of
> all its dependencies.

If zc.buildout (or setuptools, not sure which one's to blame here)  
actually had a decent algorithm for resolving dependencies, then I'd  
say you're right about reducing degrees of freedom. Sadly, it isn't  
the case.

Consider Jan Ulrich's example in this very thread:

* Jan Ulrich's app -- let's call it 'zoo' for now -- depends on  
'grok'. Grok depends on ZODB3==3.8.0b2. So it actually pins down the  
ZODB, fulfilling the job of the meta/framework egg.

* Now Jan Ulrich wants to make use of zc.sourcefactory. 'zoo' now  
depends on 'grok' and 'zc.sourcefactory'.

* 'zc.sourcefactory' OTOH depends on ZODB3 as well. Because it's a  
*library* (not a meta/framework/application egg) it doesn't and  
shouldn't pin down a version. zc.buildout isn't smart enough to  
understand that grok's requirement is more specific than this one. It  
will actually try and download the latest ZODB3 for zc.sourcefactory  
and then bail out with an error because it conflicts with the version  
pinned down for grok.


That, and the fact that it's currently impossible to override any  
version dependencies that are made with the '==' operator, I consider  
such pinnings in setup.py both ineffective (because they don't remove  
degrees of freedom for grok) and hazardous (because they constrain  
*me* instead).