[Grok-dev] Re: Python UK meeting and Django

[Martijn Faassen]

Brandon Craig Rhodes wrote:
[snip]
> Could we move the versions into setup.py? :-) I'm sorry that I keep
> asking this, because I know there's always an answer as to why we
> don't, but I can never remember.

Why we don't is because we want to give the users the flexibility to 
deviate from the versions we list. If we put them in setup.py there's no 
way to override them.

If putting them in the setup.py would fix all our installation problems, 
I personally could live with that personally, even though it'd annoy 
quite a few Zope 3 users.

One solution to make the Zope 3 users happy is to instead create a 
grok-meta package which *does* pin the versions down, but then you'd 
still need to tell people to install 'grok-meta', not 'grok'. That 
doesn't improve our situation compared to what we have now with 
grokproject; you'd still need to remember to get grok-meta instead of grok.

Anyway, let's ignore that problem for now. We put the versions in 
setup.py. Now you do 'easy_install grok'. And then what? Currently it 
doesn't set up anything up that you could can just use. Should it set up 
grokproject for you? Would this in turn set up a buildout?

One reason to encourage the use of grokproject right now is that dumping 
all that stuff into your system site-packages is really not a good idea. 
You'd have to rely on people's knowledge of tools like virtualenv.

Another feature of grokproject now on trunk is the ability to download 
an "egg basket" tarball with dependency eggs. This avoids having our 
installation process fail due to some random failure to download some 
dependency somewhere (sourceforge, say). If we told people to 
"easy_install grok", that couldn't be done (it'd need to be integrated 
into setuptools first).

We want to avoid there being too many ways to do things too. Right now 
grokproject sets up a buildout for you, and you work with that. I 
believe buildout adds nice features we don't want to do without. If we 
introduced another way to install grok, we'd need to maintain 
documentation on that too, and answer questions, and such.

It's clear though that documentation doesn't work to make people not do 
  'easy_install grok'. grok.zope.org has multiple places where it tells 
you what to do, and the grok page on pypi tells you to use grokproject 
too. It's not to clear to me how severe the problem is.

And it's true that Grok isn't particularly better than Django on this. 
That said, what you *can* do with Grok is things like 'easy_install 
martian' and 'easy_install grokcore.component' (and zope.component and 
zope.interface, etc). I understand you can't really do that with the 
bits of Django. You can't do it for *all* the bits of Grok yet, but 
we're very interested in supporting this.

Regards,

Martijn