Benji York wrote:
Derek Richardson wrote:
So, is there an easy way to do it? I know I can write a recipe, but a
recipe seems heavyweight for this. It seems to me that access to these
two values should be built into buildout as implicit variables. Is
this contrary to the lightweight, pluggable design philosophy?
The way we've handled similar needs is to require the user to enter that
kind of information in their default.cfg. That way you don't have to
sniff the environment, and the user has explicit control over what
values buildout sees.
Yeah, that explicit control is nice. But I want the easy case to be easy
- just svn co the buildout and run, no edits. So I modified the recipe
to take a user. If the user is supplied, it returns the same user. If
the user is not supplied, it returns the current user. And, in any case,
it returns the group for that user, which I don't want to specify
Oh, I just realized, you said *default*.cfg, not *buildout*.cfg. Hadn't
thought of that - that's even nicer. I will change my buildout to
However, it is only an in-house standard. Which is not to say it's a bad
idea, it's only to say 'if this is the best solution, then should we
standardize it across all buildouts, not just individual organizations?'
Then, when I check out a buildout, I can be guaranteed that it will have
access to the account I want it to have, if it needs an account for
Zope3-users mailing list