[Grok-dev] grokproject status
janwijbrand at gmail.com
Thu Apr 29 08:11:51 EDT 2010
Martijn Faassen <faassen at startifact.com> wrote:
>> * grokproject will create a "buildout.cfg" that uses this information like so
>> (with 1.1rc1 taken as an example)::
>> extends = http://grok.zope.org/releaseinfo/1.1rc1/versions.cfg
>> extends-cache = cache
> Is that the name of the directory that will be created? 'cache' is a bit
> of a generic word. I'd prefer if we called it 'versions' (that may be
> overly specific but is really what we're aiming at) or perhaps just
Hmm, right. Well, I'll go for extends-cache for now that, even though it looks a
bit weird in the buildout.cfg file itself:
extends-cache = extends-cache
But anyway, we have the same type of naming for the versions part too of course.
>> * The buildout.cfg file of a newly created project includes a [zpasswd]
>> section. It will create a cmdline tool based on code in zope.app.server to
>>> easily create
>> a zcml snippet for a new principal definition (including an correctly hashed
>> password). I do not like pulling in zope.app.server just for this feature - I
>> think it is nog used otherwise. So either we rip out this "feature" (is it
>> used by anyone?) or we re-create the script somehow - but where?
> How does grokproject itself create the initial password? If it doesn't
> use zope.app.server, shouldn't the script we generate be able to use the
> same method?
Grokproject will interpolate a SHA1 encoded password itself in the site.zcml.in
template. For that it uses a function in the utils.py module in grokproject.
I now remember a third todo item left: I want to use the SSHA1 encoding for
passwords by default. Zope's SHA1 encoding apparently is somewhat sub-optimal
and the SSHA1 implementation fixes that.
>> The development __of__ grokproject itself is now done solely in python2.6.
>> The reason was, that running the grokproject tests on Windows (on the
>> buildbot for example) will fail with missing binary eggs for python2.5. But I
>> do not think this is really a problem.
> Okay, as long as we do a manual test in Python 2.5 to see whether it
> works I think we'll be okay.
More information about the Grok-dev