[Grok-dev] Re: Python UK meeting and Django
faassen at startifact.com
Wed May 7 09:57:32 EDT 2008
Brandon Craig Rhodes wrote:
> 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.
More information about the Grok-dev