[Grok-dev] Re: cannot install a Grok app that uses "megrok.kss"

[Martijn Faassen]

Hi there,

Brandon Craig Rhodes wrote:
[snip]
> 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 
only foo"

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 
considered.

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.

Regards,

Martijn