[Grok-dev] Re: grokproject: version pinning in setup.py
faassen at startifact.com
Thu Jul 3 14:45:36 EDT 2008
Philipp von Weitershausen wrote:
> 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.
I don't think anything should be pinned in the generated setup.py; we
already do this in versions.cfg.
> Why was this done? The issue report says that it should be done, but not
No? I thought it was pretty clearly spelled out:
"With Grok, we go through a lot of trouble to make sure versions are
pinned down, to avoid new releases breaking Grok itself. We don't do
this however for grokproject, which is on the critical path to
installing Grok itself.."
The installation of grokproject is on the critical path of installing
grok. If we don't pin the versions down somehow, we risk grokproject
breaking at random points in the future. That sucks, just like it sucks
to have a grok project breaking at random points in the future. We want
to release a grokproject that works until the indefinite future.
> 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?
I know there was a problem with a botched zc.buildout release for a
while that took a while to unwedge. I don't know whether this directly
affected Grok or grokproject, but it certainly was a situation I would
not want to affect grok at any point in the future.
I would prefer to avoid the problems before we have them.
> 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).
That sucks, but that's an implementation issue. I don't know whether
it's an implementation issue we can sanely solve. Perhaps by setting up
a virtualenv-like environment, but I don't know whether that's worth it.
I want to avoid the situation where Ian Bicking releases PasteScript x.y
and accidentally or deliberately breaks the assumptions grokproject is
> I'd also like to know why it's necessary now to pin the grok version in
> a generated sandbox's setup.py.
Well, there's no good reason for that. We already do the pinning in the
More information about the Grok-dev