setting errorware configuration from the application based on other ini settings

[Thomas De Schampheleire]

Hi,

I'm setting up error reporting through e-mail in Kallithea (kallithea-scm.org), which is in transition from Pylons to TurboGears2.
In Kallithea, e-mail is used both for standard application purpose as for errors (through the web framework). As such, the .ini file has already settings such as

app_email_from
error_email_from
email_to
smtp_server
smtp_port
etc.

I understood that in TG2, errorware configuration is supposed to be set in the ini file like:
trace_errors.smtp_server = ...
trace_errors.error_email = ...

but since we need some of these settings also for 'application' emails, I want to avoid duplication. And I also think it is not correct to let the application settings derive from 'trace_errors.'.
Instead I wanted to automatically set the trace_errors settings during init, based on our existing set of ini settings.

However, I have realized that TG2 does not really support this yet: errorware is initialized already in _init_config. By the time after_init_config is reached (the place where you'd add tweaks to the configuration based on the ini file settings) any change to trace_errors.foo is no longer reflected in tg.errorware or tg.slow_reqs.

In AppConfig._init_config, there are two cases related to errorware: the standard case where the ini file contains settings under 'trace_errors.', and the backwards-compatibility case where settings are still accepted at root level, e.g. smtp_server instead of trace_errors.smtp_server. Currently I fall into this second case, which is not ideal either because it could go away in future versions of TG2.
Moreover, I recently added support for a custom smtp_port in TG2, but did not add such a backward-compatible option (because it was a new setting anyway). So, using a custom port is still not possible in my case.

The way I see it, there should be following separate steps:
1. load configuration defaults defined by the application (as set in the AppConfig object)
2. load configuration from the ini file
3. call after_init_config (or another hook) to let the application tweak the configuration if needed
4. only now start initializing turbogears, including errorware and all the rest

What is your view on this?

Thanks,
Thomas

[Alessandro Molina]

If I understand correctly, what you want to do is derive a configuration option from one that is provided in the configuration file, before the configuration file is provided to TG. As you only have an `after_init_config` hook point, but no `before_init_config` that's what's making your life hard.

I would say, that as you noticed everything is in fact stored into `tg.errorware` and you can freely change your value there in `after_init_config` as it was not yet used by TurboGears. So you can just get your option and put it into the errorware dictionary.

My solution by the way is usually to move this problem to the configuration layer. In fact the problem is that you want to reuse the same value for two different configuration options, and that is made possible by PasteDeploy itself.

So my typical configuration file in this case provides both options with a reference to the shared value. 

For Example a development.ini might look like:

# The Shared Value

set depot_backend_type = depot.io.local.LocalFileStorage

# The Actual Value for option1

get depot.storage1.backend = depot_backend_type

# The Actual Value for option2

get depot.storage2.backend = depot_backend_type

This allows me to change both option1 and option2 by changing `depot_backend_type` but still gives me the flexibility to change backend only for storage1 or storage2 whenever I want.

--
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbogears+unsubscribe@googlegroups.com.
To post to this group, send email to turbo...@googlegroups.com.
Visit this group at https://groups.google.com/group/turbogears.
For more options, visit https://groups.google.com/d/optout.

[Thomas De Schampheleire]

Hi Alessandro,

I tried this:

get trace_errors.error_email = email_to
get trace_errors.smtp_server = smtp_server
get trace_errors.smtp_port = smtp_port
get trace_errors.from_address = error_email_from

which works, but only if the values of email_to, smtp_server, ... are
effectively specified. If they are not present, this gives an error at
startup of the application.

My goal was to add the above snippet (or a variation of it) in our
default ini files, and ini file template, so that users don't need to
care about it. However, we do not have default values for these
settings.

Do you know how to achieve this?

Also, I couldn't find documentation for these 'get' keyword. The 'set'
is documented in PasteDeploy documentation, but 'get' is not.

Thanks,
Thomas

[Thomas De Schampheleire]

Kind reminder..

[Alessandro Molina]

Not sure there is a way to achieve that. 

As `get` copies the value of an option from the value value of the global, what should be the value for a global that doesn't exist?

In this specific case I think you might want to provide a default by setting "email_to=" so that `get trace_errors.error_email = email_to"  can work but error email is disabled as it's empty.