On 1/11/13 9:27 PM, Olemis Lang wrote:
On 1/11/13, Jure Zitnik <[email protected]> wrote:
[...]
So I was playing with an idea to introduce global.ini (or boot.ini or
something like that) that would be located on a well-known location in
the installation tree (trac.env_parent_dir for example) and would hold
global (=common for all environments) settings (custom hooks for
starters). The question is where this configuration is supposed to be
loaded/processed. trac/__init__.py would be one place but I'm not sure
that's the right one :)
IMO there's no reason to spend some time developing something new for
this to happen . The reason is *not* that your reasoning is not
correct . The fact is that this (configuration inheritance) has been
already there since a long time .
I'm aware of the configuration inheritance, the problem is that
inheritance by itself does not solve the issue. Let me try to elaborate
on the problem a bit more ;)
What I'm trying to achieve is to monkey patch trac.env.Environment and
trac.db.util.IterableCursor. To enable multi-product support, both
classes should be replaced by our implementation, namely with
multiproduct.env.Environment and
multiproduct.dbcursor.BloodhoundIterableCursor. As things are currently
implemented, the code that does monkey patching (hooks) is executed
inside trac.web.main.dispatch_request. At this point, the environment
(based on the URL) has already been selected (but not instantiated!) so
the hook path can be read from that specific environment's configuration
(as the path to the .ini is known) and hooks can be executed. This
happens just before trac.env.open_environment and thus the
open_environment already instantiates multiproduct.env.Environment. So
this works fine when running within a web request (through
trac.web.main.dispatch_request).
But, there is code that doesn't at all get executed through that
(dispatch_request) execution path. Example would be tests. To enable
multi-product functionality in test code (or any other code that doesn't
get executed through dispatch_request), the hooks (monkey patching)
should be executed rather soon, before the first trac.env.Environment
gets instantiated. So, the question is how to achieve that. Note that
there is no 'environment' at that point. The idea was to have a
global.ini or something similar on a well known path (not really sure
what that would be though). trac/__init__.py would be modified to load
configuration from that well known path and execute configured hooks.
If this approach (configurable hooks) is not feasible, we can always
hardcode them in trac/__init__.py ...
Cheers,
Jure
