[Grok-dev] Re: cannot install a Grok app that uses "megrok.kss"
faassen at startifact.com
Thu Apr 17 07:11:08 EDT 2008
Brandon Craig Rhodes wrote:
> Why, again, aren't we normal Python citizens who just put version
> information right in the setup.py? ;-)
The disadvantages of hard-coding versions on a granular level:
* if we say foo 1.3 depends on bar 1.2, people can't override this
anymore even if they know bar 1.2.1 will work.
* if we waltz in and say that zope.component depends on foo 1.2, people
who are combining these Zope packages in another will be grumpy.
This, unfortunately, defeats the idea of consistently locking in
versions everywhere. This *would* make installing those packages way
more reliable, but does break flexibility.
One concept I've been playing around with for quite a while but haven't
had time to implement is to change setuptools so you can express
something like this in setup.py:
"This package *will* work with foo 1.2, but really the requirement is
You'd then need to modify setuptools and/or buildout to pick the fixed
version all else being equal, unless this is overridden by an outer
package. I think this approach would introduce reliability while not
breaking flexibility, but even this might have problems I haven't
Since implementing all this would mean a lot of work, with Grok we've
gone for the simpler approach and pin these things down in buildout.
Advantage is that you can still easily override versions in your own
application if you want to.
I think we should however also come up with a way that doesn't depend on
buildout.cfg. The solution would be a special grok meta-package that
does lock down all dependencies. The repoze project has a way to produce
one from our versions list already. If we publish this grok-meta
package, we can ensure that those who install grok using that will get a
consistent version. That wouldn't have solved the problem with your
older buildouts unfortunately, however.
More information about the Grok-dev