Comment 3 for bug 242370

On Tue, Jul 1, 2008 at 12:06 PM, maurits <email address hidden> wrote:
> As for the zc.buildout dependency of grokproject itself: in my own
> (Plone) buildouts I never pin zc.buildout or setuptools in the
> version.cfg as a bootstrap will always get the newest versions of those
> two and will then give a conflict error when running bin/buildout after
> that. So I am inclined to not pin those in the setup.py of grokproject
> or a generated project either.

Yes, we've been doing this for grok as well, but I actually consider
this to be the wrong behavior. It's quite possible for a broken
buildout version or recipe version to be released. For buildout, I
know a broken buildout version was released not long ago, for
instance.

I realize that this doesn't have an easy solution, but the goals are:

* release grokproject and be sure that when it is installed, it will
only use well-known fixed versions of all its dependencies

* be able to install a grokproject generated grok project and be sure
it will only use a well-known fixed version of buildout and its
recipes.

The goal is repeatability. We don't want a situation where we have a
working grokproject, someone releases a botched recipe, paste or
buildout, and suddenly the process fails.

(I agree versions in a grokproject generated buildout should not be
pinned down in the setup.py, by the way. We never should generate
anything with grokproject that pins things down in setup.py.)

P.S. This is not a critical issue, as we work in the less reliable way
already. I just would like to think about a solution.