grokproject should pin versions
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
grok |
Fix Released
|
Medium
|
Maurits van Rees | ||
1.0 |
Fix Released
|
Medium
|
Maurits van Rees |
Bug Description
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...
I think we should pin down the (non-test) dependencies in grokproject to actual versions. This can be easily done for PasteScript. I'm a bit more concerned about pinning down zc.buildout - I wonder what the interactions are to installing and using buildout here. This needs to be investigated.
In addition, I think we should also pin down the buildout eggs that grokproject generated buildout.cfg relies on.
So:
* pin down dependencies of grokproject
* pin down recipe dependencies of buildout.cfg generated by grokproject
Changed in grok: | |
assignee: | nobody → maurits-vanrees |
importance: | Undecided → Medium |
Changed in grok: | |
milestone: | none → 1.0 |
I pinned the grok version in the generated setup.py; committed in r87875.
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.
As for PasteScript: when I change the dependency from "PasteScript>=1.6" to "PasteScript= =1.6.3" I get this error when running bin/buildout in my grokproject checkout:
======= ======= ======= ======= ======= =1.6.3' . ======= ======= ======= =======
While:
Installing grokproject.
Error: There is a version conflict.
We already have: PasteScript 1.6.2
but grokproject 0.8dev requires 'PasteScript=
=======
Ah, but of course when running "bin/buildout -nv" it gets the new requirement. So that should be fine; committed in r87877.