[Zope3-dev] Re: Autoconfiguring a site.zcml

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Faassen wrote:
> Hello,
> 
> Tres Seaver wrote:
>> David Pratt wrote:
>>> On the basis that eggs spell out dependencies, I am thinking the 
>>> inclusion of packages and their dependencies should be enough to dictate 
>>> the sequence of inclusion for package configuration (and creation of the 
>>> site.zcml) for the app buidout recipe. This could be a option to the 
>>> current manual configuration.
>> - -1.  Configuration is *policy*;  implicitly wiring in the default
>> configuration for every egg on the path is not going to be an acceptable
>> default.
> 
> In the path? David didn't say in the path, did we? What about in the 
> buildout? Since my buildout already says explicitly it wants egg foo, 
> and egg foo needs egg bar, it is a major pain to have to specify the 
> ZCML for bar manually.
> 
> I don't think something being policy means it's automatically a bad 
> candidate for automation. Information about the policy may after all be 
> elsewhere in the system, for instance in a buildout.cfg.

You don't see cases already where you want to use something from
somebody else's package / egg, but don't want to accept every
configuration choice they make?  This is pretty hard to do if the system
automagically wires in every pacakge's 'configure.zcml'.  One of the big
knocks against Zope2's 'product" story was exactly this:  there was no
way to use a product without accepting its entire "configuration."

>>> Presumably, the reason folks would use this recipe is to configure one 
>>> or more of the same app. I know attempting to do this manually is prone 
>>> to errors if packages are not in the correct sequence or if you miss the 
>>> configuration of a package. Any thoughts on this. Many thanks.
>> Not necessarily.  There are really two kinds of packages in play here:
>> "libraryish" packages, which supply mechanisms, and "applicationish"
>> packages, which use the mechanism according to some policy.  I would
>> argue that the only things you can safely auto-include would be the
>> 'meta.zcml', because it is policy-free.  Reusable packages need to avoid
>> imposing policy (they may *suggest* it, but they shouldn't insist).
> 
> That's where we have the concept of overridable defaults. So the default 
> should be to follow the suggestions, and there should be an option in 
> the system to override this suggestion.

There is not such place right now.  The 'includeOverrides' directive is
not expressive enough.

>> I would cheer if somebody proposed writing a UI which introspcts
>> packgaes for such suggestions, and allows the site manager to merge /
>> override them to create an appropriate 'site.zcml'.  Until then, I don't
>> want package authors dictating to site managers.
> 
> Who are these ZCML-using site managers you are speaking of? Anyway, are 
> you saying you want some form of ZCML UI to be created before *any* 
> automation can be implemented? Asking for the creation of a UI on the 
> Zope 3 mailing list is paramount to waiting forever...

*I* am the user I'm talking about:  I want to be able to use others'
components without swallowing whole their configuration choices;  today,
that means copying and modifying their 'configure.zcml' files.

> If you never automate policy, you'll be writing a lot of stuff by hand. 
> That may be fine for you, but I myself would prefer to write less boring 
> code and focus on more interesting problems.

Automation which is hard to understand and override is the source of the
"Z shaped learning" curve which plagued Zope2;  it also plagues other
convenience-oriented frameworks outside of Zopeland.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGK4lm+gerLs4ltQ4RApoUAJ4g8t3xOSqAsIAcIawKy0xwgYrBqACeKoxJ
2Bq3bKeJZkT+sf/bxx5UUMQ=
=TbFf
-----END PGP SIGNATURE-----