[Grok-dev] Re: grokproject: version pinning in setup.py

[Philipp von Weitershausen]

Maurits van Rees wrote:
> Philipp von Weitershausen, on 2008-07-01:
>> As stated in https://bugs.launchpad.net/bugs/242370, grokproject now  
>> pins the versions of its dependencies (PasteScript etc.) in its  
>> setup.py. Also, apparently a generated sandbox also pins the grok  
>> version in setup.py.
>>
>> Why was this done? The issue report says that it should be done, but  
>> not why. I also don't recall ever discussing this, though I haven't  
>> been following every thread on the list. Was there ever a problem with  
>> installing grokproject due to the lack of pinned versions? The issue  
>> doesn't seem to include an actual bug report and I don't recall a  
>> similar incident either. Quite frankly, I fail to see the benefit of  
>> pinning PasteScript etc. We already used to specify a lower bound  
>> (e.g. >=1.6) where necessary, which ensured people got *at least* a  
>> working version. Pinning the version with == is likely to go wrong  
>> anyway, e.g. when you install grokproject and it wants  
>> PasteScript==1.6 and then some other package wants 1.7, setuptools  
>> will simply install the 1.7 version and grokproject's pinning will be  
>> broken, without any error message telling you (I just verified this).
> 
> 1.7 is not out yet, so that would be hard to test... Or did you verify
> this with a different package?

Different package. I just chose these numbers to illustrate the point.

> The reasoning would be similar to the reasoning of pinning down the
> versions of zope packages in the KGS and the version.cfg of grok
> itself: a newer version of some package may break your project.
> 
> For PasteScript I do not expect big changes so keeping the dependency
> to just a minimum version *should* be fine; but there is no guarantee.

Certainly there's a risk, but unlike with the various Zope packages, we 
haven't actually experienced problems. Also, the number of dependencies 
that grokproject has is an order of magnitude smaller than Grok's.

> Then again, in case grokproject 0.8 breaks in practice turns out to
> actually break with a newer PasteScript, we can always ship
> grokproject 0.8.1 with a more strict pinning in setup.py.
> 
> Martijn, since you brought this issue up: can you think of a good
> reason to stick to an explicit version for PasteScript?  If not, I can
> revert that change.
> 
>> I'd also like to know why it's necessary now to pin the grok version  
>> in a generated sandbox's setup.py.
>> Have we had problems that are solved by pinning it in setup.py *in  
>> addition* to buildout.cfg? Again, the checkin message just says  
>> "Pinned the required grok version in the generated setup.py.", but it  
>> doesn't say why.
> 
> My reasoning was that this would make it easier to fit an easy_install
> style setup without zc.buildout.  When you easy_install a generated
> grokproject, and this just has an unpinned dependency on grok, you
> could get a more recent grok version that this generated grokproject
> does not work with, or is not verified against.
> 
> But I see that reasoning is a bit silly: that would mean newly
> generated grokprojects would currently have a hard dependency on 0.13
> and would give a conflict error when used with a future 0.14 or even
> 0.13.1; that is not what we want.

Also, just pinning grok itself is silly. We've never had a problem with 
implicit Grok updates, just with all the other gazillion packages from 
zope.* :).

If anybody wanted to serve the non-zc.buildout scenario, then s/he 
should create a custom locked-down index that you can point easy_install 
to (repoze does it this way, for instance).

Perhaps we should serve such a locked down index on grok.zope.org for 
each Grok version (can't be too hard, both the Zope project and Repoze 
have software for generating such an index) and thus give people the 
choice to simply use easy_install (and python setup.py develop for their 
sandbox). However, the locked down index won't support upgrading one 
particular package out of Grok's dependencies. It also doesn't allow 
locking down another 3rd party package other than in your own setup.py. 
The solution is, of course, to create your own locked down index just 
for that project (which is a bit like writing a version.cfg for 
zc.buildout, except more complicated).

> One thing I wonder: do we instead want a dependency like "grok>=0.13"?
> I guess not though.

Maybe, though it seems unnecessary.