[Grok-dev] Re: grokproject: version pinning in setup.py
Maurits van Rees
m.van.rees at zestsoftware.nl
Tue Jul 1 08:44:17 EDT 2008
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]
More information about the Grok-dev