| 2009-01-13 16:39:49 |
Martijn Faassen |
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. |
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
|
|
