[Grok-dev] grokproject status

[Jan-Wijbrand Kolman]

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)::
>> 
>>   [buildout]
>>   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 
> 'extends-cache'.

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.

Yes.

regards, jw