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

[Maurits van Rees]

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?

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

So at least a hard pinned dependency does not seem like a good idea
after all.  I will revert that change.

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

-- 
Maurits van Rees | http://maurits.vanrees.org/
            Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]