[Zope3-dev] Re: Autoconfiguring a site.zcml
Martijn Faassen
faassen at startifact.com
Mon Apr 23 15:25:19 EDT 2007
Jim Fulton wrote:
>
> On Apr 23, 2007, at 2:43 PM, Martijn Faassen wrote:
> ...
>> It'd be a lot easier. You'd still have to list it for all eggs that
>> you depend on directly. It would be nice if this could be automated as
>> well, as being in two places to add a single dependency is more work
>> than being in one place. Could be done with a special recipe, I think.
>
> Except that the information belongs in your application package's
> configure.zcml. site.zcml should, IMO, be a very short file that
> include's your application package's configure.zcml. If you want to
> write a tool that writes your configure.zcml, go for it.
> I wouldn't object to a zcml configuration directive that took a project
> name and included zcml files provided by it's dependencies at run time.
Yes, that would be useful. I will think about it. Preferably it should
be somewhat ZCML independent so Grok can make use of it too.
>> Package-level ZCML include dependencies would also mean a kind of
>> duplication, too. You list dependencies in setup.py and then again in
>> the package's ZCML.
>
> You could argue that the dependencies in setup.py duplicate information
> in your Python import statements -- if you wanted to.
Good point, but I don't want to argue that. :) Anyway, automating egg
dependencies from import statements is somewhat harder as some
information is missing (egg name, version requirements). An interesting
project. :) Not urgent, though.
I realize I'm quite active in looking for points of duplication to
reduce. I don't think it's a bad exercise for any framework to do this.
[snip]
>> I can see how -o is the most deterministic buildout behavior, as it
>> will upgrade nothing. The next step in my mind would be -N, as it only
>> installs what's not there yet. Finally there's "no option", which is
>> least predictable it might start updating stuff, depending on what
>> package restrictions you have. Obviously I'm not understanding what
>> you mean by "deterministic".
>
> The default behavior is to update all packages to the most recent
> version that satisfies your requirements. This means that running
> buildout in 2 different buildouts with the same configuration should
> produce the same results, regardless of their history. I think this is
> an important property that you lose with -N.
Ah, understood. I hadn't thought of this in the context of multiple
buildouts, but that's of course an important property for team
development situations.
>>> It is easy for people to change the default for their own use by
>>> putting:
>>> [buildout]
>>> newest = false
>>> in their ~/.buildout/default.cfg file.
>>
>> Ah, a trick I wasn't aware of. I will do that then in my
>> buildout.cfgs, though this will indeed might cause a few surprises to
>> people they might get used to it and be surprised when they need -N in
>> other buildouts.
>
> That's why I suggested putting it in: ~/.buildout/default.cfg, which
> would effect only you.
Ah, I should read more carefully, sorry. I should also look up the
explicit option to turn on newest again to make sure I can develop as
part of a team. :)
Regards,
Martijn
More information about the Zope3-dev
mailing list