Extending Zope's ZConfig Schema in a Product?
Hello, I've been hitting my head against the wall for a few hours already, so I thought it would be a good time to ask before the house falls apart *wink*. I'm looking back and forth between the Zope and ZConfig sources and documentation to see if I can figure out how to have a Product (or a python package) to extend Zope's ZConfig schema (a.k.a. Zope/Startup/zopeschema.xml) without having to reach into the guts of ZConfig. It looks like the right way to do this would be to extend Zope's schema and then specify a different 'schemafile' to ZopeOptions, but that's not currently possible as Zope doesn't support the '-S schemafile' switch that ZDCtlOptions does. If what I'm looking for seems just stupid please tell me *wink*. All I want to do is to add a simple config 'key' to zope.conf without having to patch the Zope source. Having no other choices, I would go with having my own schema and configfile, but that would be sub-optimal. Thank you for any help, -- Sidnei da Silva Enfold Systems, LLC.
I'm looking back and forth between the Zope and ZConfig sources and documentation to see if I can figure out how to have a Product (or a python package) to extend Zope's ZConfig schema (a.k.a. Zope/Startup/zopeschema.xml) without having to reach into the guts of ZConfig.
The config file syntax has a "%import" directive that allows you to add another package to handle certain config directive. That package than can contain a an XML file that describes your new configuration directives and the code to handle them. I posted a small sample a few months ago here: <http://mail.zope.org/pipermail/zope-dev/2005-January/024244.html>
On Thu, Jun 30, 2005 at 10:21:40PM -0400, Andrew Langmead wrote: | The config file syntax has a "%import" directive that allows you to | add another package to handle certain config directive. | That package than can contain a an XML file that describes your new | configuration directives and the code to handle them. Gosh, that looks too nice to be true. I will try that out tomorrow and write out a how-to on zope.org if it works out. -- Sidnei da Silva Enfold Systems, LLC.
On 6/30/05, Sidnei da Silva <sidnei@enfoldsystems.com> wrote:
Gosh, that looks too nice to be true. I will try that out tomorrow and write out a how-to on zope.org if it works out.
It is too good to be true; sorry. Well, it is true, but it's not what you're looking for. You can't use it to extend the schema for Zope. You can use it to add new concrete implementations for things that are allowed; the original use-case was to allow things like new kinds of storage for the database. I've spent a little time thinking about this issue, and have come up with at least one way to deal with it (and %import would be used, in part), but I've never been completely happy with the approaches. Since using an additional configuration file is possible (and quite easy in Zope 2, since the location of the instance is so easy to discern, I'm not convinced it's actually important to support embedding the configuration for 3rd-party components into zope.conf. If you want something you can use now, using a product-specific configuration file, with an appropriate schema, will do quite well. It also doesn't require hacking (or monkey-patching) Zope or ZConfig, so it would be easy to deploy in a variety of situations. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> Zope Corporation
On 1 Jul 2005, at 04:58, Fred Drake wrote:
Since using an additional configuration file is possible (and quite easy in Zope 2, since the location of the instance is so easy to discern, I'm not convinced it's actually important to support embedding the configuration for 3rd-party components into zope.conf. If you want something you can use now, using a product-specific configuration file, with an appropriate schema, will do quite well. It also doesn't require hacking (or monkey-patching) Zope or ZConfig, so it would be easy to deploy in a variety of situations.
That just has the disadvantage that you're increasing the number of configuration files to maintain in an instance. If it's imported and used in zope.conf at leaast there's just one file to deal with... jens
On 7/1/05, Jens Vagelpohl <jens@dataflake.org> wrote:
That just has the disadvantage that you're increasing the number of configuration files to maintain in an instance. If it's imported and used in zope.conf at leaast there's just one file to deal with...
This is true. Is that really important, though? Adding this ability would be a new feature, so not available until 2.9. I got the impression people want to do this now. It makes a lot more sense to pick something that can be used both now and into the future than hack something together. If someone wants to create a way to manage product-specific configurations in a single file, it's not hard to create a Python package to support that, and products that want to have their configuration placed in that file could set themselves up to use %import in that file. I've no need of that myself, but others are certainly welcome to create such a package; it may be a reasonable addition for 2.9, and could be distributed separately for use with 2.7/2.8. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fred Drake wrote:
On 7/1/05, Jens Vagelpohl <jens@dataflake.org> wrote:
That just has the disadvantage that you're increasing the number of configuration files to maintain in an instance. If it's imported and used in zope.conf at leaast there's just one file to deal with...
This is true. Is that really important, though?
Adding this ability would be a new feature, so not available until 2.9.
While that is the "correct" policy, I would argue that a fully-backward-compatible extension like this would be a sensible extension, at least until we establish a track record with the new "time-based" release policy. If necessary, we could implement it in the same way that Five did for Zope 2.7, by creating a product which does a controlled monkey-patch for the 2.8 (or even 2.7) releases, and then incorporating that product, minus the monkey patch, for 2.9.
I got the impression people want to do this now. It makes a lot more sense to pick something that can be used both now and into the future than hack something together.
If someone wants to create a way to manage product-specific configurations in a single file, it's not hard to create a Python package to support that, and products that want to have their configuration placed in that file could set themselves up to use %import in that file.
I've no need of that myself, but others are certainly welcome to create such a package; it may be a reasonable addition for 2.9, and could be distributed separately for use with 2.7/2.8.
Ah, yes, I should read the whole message first. ;) +1 for the "product-includes/*" directory notion, by the way. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCxqz9+gerLs4ltQ4RApLJAKDZioI4j3py235UnDh9B6ZetvAXWgCgz6wb 8Qd/4u01EpfL7lPghwj8vcU= =sXqy -----END PGP SIGNATURE-----
On Thu, Jun 30, 2005 at 11:58:08PM -0400, Fred Drake wrote: | On 6/30/05, Sidnei da Silva <sidnei@enfoldsystems.com> wrote: | > Gosh, that looks too nice to be true. I will try that out tomorrow and | > write out a how-to on zope.org if it works out. | | It is too good to be true; sorry. | | Well, it is true, but it's not what you're looking for. You can't use | it to extend the schema for Zope. You can use it to add new concrete | implementations for things that are allowed; the original use-case was | to allow things like new kinds of storage for the database. Yeah, I can see two things of doing it by *abusing* zope.conf, one is abuse the 'server' abstract type and the other is to use the 'environment' directive, but then you can't specify the datatype. Oh, well. | I've spent a little time thinking about this issue, and have come up | with at least one way to deal with it (and %import would be used, in | part), but I've never been completely happy with the approaches. I would like to suggest something like what's done for Zope 3 with 'package-includes'. Then '<package-name>-schema.xml' would be included from 'zopeschema.xml' and '<product-name>-zope.conf' would be included from 'zope.conf'. Actually, maybe not even a special directory, but looking inside the Products directories for those files. But then there would be a chicken-and-egg problem because of the 'products' directive in zope.conf. Maybe a special directory is the best in this case. | Since using an additional configuration file is possible (and quite | easy in Zope 2, since the location of the instance is so easy to | discern, I'm not convinced it's actually important to support | embedding the configuration for 3rd-party components into zope.conf. | If you want something you can use now, using a product-specific | configuration file, with an appropriate schema, will do quite well. | It also doesn't require hacking (or monkey-patching) Zope or ZConfig, | so it would be easy to deploy in a variety of situations. Right, seems that's my only choice for the time being. -- Sidnei da Silva Enfold Systems, LLC.
Sidnei da Silva wrote:
Right, seems that's my only choice for the time being.
We currently do this in our 'start Z3' script before any of the Zope imports are done: # Disgusting hack to use our extended config file schema rather than the # Z3 one. TODO: Add command line options or other to Z3 to enable # overriding this -- StuartBishop 20050406 from zdaemon.zdoptions import ZDOptions ZDOptions.schemafile = the_path_to_our_schema_dot_xml You can then write a schema.xml that inherits from the Z3 one: <schema extends="../../zope/app/server/schema.xml"> <sectiontype name="foo"> <key name="bar" datatype="string" default="Fnord" /> </sectiontype> <multisection name="+" type="foo" attribute="foo" /> </schema> We are trying to centralize all our knobs and buttons into one place - ZCML isn't suitable for tweaking an application being rolled out to multiple servers (dev boxes, staging servers, production server instances) because there is too much boilerplate and syntax around the knob you need to tweak, and way too complex for a drunk sysadmin to handle. eg. it is much easier to have 'smtp on' in launchpad.conf than it is to configure the correct IMailer directives and whatnot with he correct magic names so that the application sends email via SMTP rather than sendmail. So far, ZConfig has been way overkill for this but allows us to keep our config in the same config as the port numbers and logfile destinations (without having to generate it from some other source, which we will probably do in the future to solve some production rollout issues). -- Stuart Bishop <stuart@stuartbishop.net> http://www.stuartbishop.net/
On Mon, Jul 04, 2005 at 12:19:59PM +1000, Stuart Bishop wrote: | Sidnei da Silva wrote: | | > Right, seems that's my only choice for the time being. | > | | We currently do this in our 'start Z3' script before any of the Zope imports | are done: | | # Disgusting hack to use our extended config file schema rather than the | # Z3 one. TODO: Add command line options or other to Z3 to enable | # overriding this -- StuartBishop 20050406 | from zdaemon.zdoptions import ZDOptions | ZDOptions.schemafile = the_path_to_our_schema_dot_xml Which brings us back to one of the original issues: zopectl/runzope does not support an option to change the schema file from the command line, while zdctl seems to. Now if that's intentional is a different story. I would classify this as a bug that has been overlooked. | You can then write a schema.xml that inherits from the Z3 one: | | <schema extends="../../zope/app/server/schema.xml"> | <sectiontype name="foo"> | <key name="bar" datatype="string" default="Fnord" /> | </sectiontype> | | <multisection name="+" type="foo" attribute="foo" /> | </schema> Yes, that's exactly the kind of thing I'm after. -- Sidnei da Silva Enfold Systems, LLC.
FWIW, I don't know if it helps at all, but there's a concrete example of allowing a 3rd-party product to add a section to zope.conf via %import in the ClockServer product at http://www.plope.com/software/ClockServer/ . It sounds from your description exactly like what you want to do, although it adds a section rather than just a key, which might be fine for your case. On Thu, 2005-06-30 at 23:12 -0300, Sidnei da Silva wrote:
Hello,
I've been hitting my head against the wall for a few hours already, so I thought it would be a good time to ask before the house falls apart *wink*.
I'm looking back and forth between the Zope and ZConfig sources and documentation to see if I can figure out how to have a Product (or a python package) to extend Zope's ZConfig schema (a.k.a. Zope/Startup/zopeschema.xml) without having to reach into the guts of ZConfig.
It looks like the right way to do this would be to extend Zope's schema and then specify a different 'schemafile' to ZopeOptions, but that's not currently possible as Zope doesn't support the '-S schemafile' switch that ZDCtlOptions does.
If what I'm looking for seems just stupid please tell me *wink*.
All I want to do is to add a simple config 'key' to zope.conf without having to patch the Zope source.
Having no other choices, I would go with having my own schema and configfile, but that would be sub-optimal.
Thank you for any help,
On 7/1/05, Chris McDonough <chrism@plope.com> wrote:
FWIW, I don't know if it helps at all, but there's a concrete example of allowing a 3rd-party product to add a section to zope.conf via %import in the ClockServer product at http://www.plope.com/software/ClockServer/ . It sounds from your description exactly like what you want to do, although it adds a section rather than just a key, which might be fine for your case.
I'll note what you didn't. ;-) This works for ClockServer because you're adding a server type, and those are already allowed in the Zope configuration. This doesn't cover the case of a section that isn't an "implementation" of an abstract section type already accepted by the Zope configuration (log handlers, servers, databases, storages... that's all I can remember off the top of my head). The general case of being able to add a section (or anything else) isn't covered by the current implementation. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> Zope Corporation
On Fri, Jul 01, 2005 at 08:27:02AM -0400, Fred Drake wrote: | On 7/1/05, Chris McDonough <chrism@plope.com> wrote: | > FWIW, I don't know if it helps at all, but there's a concrete example of | > allowing a 3rd-party product to add a section to zope.conf via %import | > in the ClockServer product at | > http://www.plope.com/software/ClockServer/ . It sounds from your | > description exactly like what you want to do, although it adds a section | > rather than just a key, which might be fine for your case. | | I'll note what you didn't. ;-) This works for ClockServer because | you're adding a server type, and those are already allowed in the Zope | configuration. | | This doesn't cover the case of a section that isn't an | "implementation" of an abstract section type already accepted by the | Zope configuration (log handlers, servers, databases, storages... | that's all I can remember off the top of my head). | | The general case of being able to add a section (or anything else) | isn't covered by the current implementation. That is right. I've just learnt that the hard way *wink*. -- Sidnei da Silva Enfold Systems, LLC.
On Fri, 2005-07-01 at 10:54 -0300, Sidnei da Silva wrote:
| The general case of being able to add a section (or anything else) | isn't covered by the current implementation.
That is right. I've just learnt that the hard way *wink*.
Oh. ;-) - C
participants (7)
-
Andrew Langmead -
Chris McDonough -
Fred Drake -
Jens Vagelpohl -
Sidnei da Silva -
Stuart Bishop -
Tres Seaver