[Grok-dev] Re: gocept.zope3instance

[Christian Theune]

Hi,

Am Donnerstag, den 11.01.2007, 12:22 +0100 schrieb Philipp von
Weitershausen:
> On 11 Jan 2007, at 12:10 , Christian Theune wrote:
> >> I have two bug reports to make:
> >>
> >> 1.) The advertised "user = user:passwd" doesn't work. Instead, it  
> >> wants
> >> "admin-user = user" and "admin-password = passwd". This isn't so  
> >> much of
> >> a bug as a documentation issue. Btw, it doesn't look like it supports
> >> password managers for encrypted passwords. I wonder if
> >> zc.recipe.zope3instance does...
> >
> > Thanks. Updated in SVN.
> 
> Thanks. You might also want to "python setup.py register" again to  
> update the Cheeseshop page.

Uhh. Ah. To update the docs.

> >> 2.) When the recipe fails, e.g. due to a missing configuration  
> >> option in
> >> buildout, it exits gracefully with a nice error message (I assume the
> >> error message comes from zc.buildout). When you fix the problem in  
> >> your
> >> buildout.cfg and want to run the buildout again, gocept.zope3recipe
> >> complains that it can't create the instance directory again. The  
> >> problem
> >> is this line:
> >>
> >>          # XXX In theory we could just delete the parts directory  
> >> here,
> >> if it
> >>          # exists already. Or not?
> >>          os.mkdir(dest)
> >
> > This is not so clear unfortunately, at least to me. I've gotta ask Jim
> > about what this means in buildout terminology ...
> 
> Hmmm, I guess. zc.recipe.zope3recipe at least deletes the whole  
> instance and recreates it every time you call bin/buildout. That's  
> not really an option, of course, when you're using buildout to update  
> a production environment, or you need to keep your Data.fs around  
> even for development.
> 
> I certainly wouldn't want bin/buildout to delete Data.fs in a  
> grokproject-created buildout.

That's why the database has its own part and doesn't tell buildout to
manage the part's directory.

> Huh? The Cheeseshop page says something else.

Updated.

> > We have created an approach where you can created a derived version  
> > of the ZCML
> > and add your pieces there.
> 
> Example?

The instance recipe defines a skeleton with the basic ZCML stuff.
However, I've used as little ZCML as possible. I'm not sure that a
single set is enough. Also, the recipe will have to deal with different
Zope 3 versions and figure out which ZCML to actually use.

You can also define another overlay buy creating a directory
"skels/<partname>" in your buildout. All the files in the will be copied
into the part, after the built-in skeleton was copied. Then, all ".in"
files get renamed and string-interpolation form the part's configuration
happens.

> > The exact structuring needs more discussion
> > though. Eventually we want to provide multiple profiles of  
> > skeletons in
> > the recipe.
> 
> Aha. Use case?

See above.

Christian

-- 
gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/grok-dev/attachments/20070111/c9750fb5/attachment.bin