CORE - Provide a mechanism to use custom ini files

[ilias@…]

The trac.ini file becomes larger and larger.

It would be of benefit to have a standard mechanism to provide further configuration *.ini files.

This could be achieved by e.g.:

a) IIniProvider extension point (or similar)

b) decoupling the relevant ini-processing code, thus it can be reused easily e.g. within larger plugins.

b) is possibly already achieved, don't know the relevant code

context:  http://dev.lazaridis.com/base/ticket/80

[Tim Hatch <trac@…>]

Ilias, I don't understand what this is ticket is supposed to be about. Correct me if I'm wrong:

1. (in this ticket). provide some way to load configuration from locations other than the main trac.ini. Is this to be just a mechanism to make Trac read additional ini files, and if so, how are they supposed to be specified?
2. (the first 'b' in this ticket). what? how is the "relevant ini-processing code" not currently "decoupled"? (a word I notice you love to use).
3. (in the two-line ticket you linked to). "dedicated ini-file" means to simplify multiple installs, or what?

[ilias@…]

Replying to Tim Hatch <trac@timhatch.com>:

Ilias, I don't understand what this is ticket is supposed to be about. Correct me if I'm wrong:

ok

a. (in this ticket). provide some way to load configuration from locations other than the main trac.ini.

yes.

Is this to be just a mechanism to make Trac read additional ini files, and if so, how are they supposed to be specified?

A plugin which would contain an Component which implements the IIniProvider Interface (to be implemented).

b. (the first 'b' in this ticket). what? how is the "relevant ini-processing code" not currently "decoupled"?

by having dependencies other code units.

but as said, "b) is possibly already achieved, don't know the relevant code"

(a word I notice you love to use).

decoupling = eliminate coupling (dependencies) between functional units.

nothing special.

c. (in the two-line ticket you linked to). "dedicated ini-file" means to simplify multiple installs, or what?

to simplify the installation of a custom trac version, which is mainly based on one plugin (tracx).

[sid]

Replying to ilias@lazaridis.com:

Replying to Tim Hatch <trac@timhatch.com>:

b. (the first 'b' in this ticket). what? how is the "relevant ini-processing code" not currently "decoupled"?

by having dependencies other code units. but as said, "b) is possibly already achieved, don't know the relevant code"

Trac uses Python's built-in  ConfigParser for reading in data from TracIni.

[sid]

More info here: source:trunk/trac/config.py

[cboos]

Replying to sid: I'd even say: look at log:trunk/trac/config.py, in particular look for IConfigurable ;)

[ilias@…]

Replying to cboos:

Replying to sid: I'd even say: look at log:trunk/trac/config.py, in particular look for IConfigurable ;)

The pointers provided by 'sid' are helpfull.

It would be nice if you could point me to some documentation, and not to logfiles where I (and other's which hit on this ticket) have to 'fish out' the information.

I can't see a existent / documented way of providing an own ini-file.

[Noah Kantrowitz (coderanger) <coderanger@…>]

 http://www.python.org/doc/2.4.3/lib/module-ConfigParser.html

Crazy go nuts.

[ilias@…]

Replying to Noah Kantrowitz (coderanger) <coderanger@yahoo.com>:

 http://www.python.org/doc/2.4.3/lib/module-ConfigParser.html

the link to config-parser was already given.

Crazy go nuts.

I don't know the reason for this comment.

I am within the trac project, and I ask for a construct to provide a custom ini file (not custom ini sections ).

As stated, of course I like to reuse the functionality provided by trac.

The documentation does not state a way (or at least I couldn't find one).

And it looks like the config.py code is coupled to some internals. Can someone confirm/deny?

[sid]

Replying to ilias@lazaridis.com:

I am within the trac project, and I ask for a construct to provide a custom ini file (not custom ini sections ). As stated, of course I like to reuse the functionality provided by trac. The documentation does not state a way (or at least I couldn't find one). And it looks like the config.py code is coupled to some internals. Can someone confirm/deny?

From r3180:

Fairly large change to the recently introduced IConfigurable mechanism that lets plugins declare options they support in trac.ini.

Instead of using an extension point, the new mechanism uses descriptors (one of Option, BoolOption, IntOption, ListOption, or ExtensionOption) that can be added to any class (but especially Component subclasses), allowing direct access to the configured value. The Option class keeps a registry of all declared options, so that the defaults also work when the option is accessed through the Configuration object.

See also r3067.

So the short answer is that you can use the extension point to add sections to trac.ini very easily. If you want your own custom .ini file, then you can use the previously referred to ConfigParser that is provided by Python. Trac's config.py is only a thin layer on top of it.

[ilias@…]

Replying to sid:

The information you provide confirms that the functionality is missing from core.

So, this ticket is about enhancing the current status of the trac core whilst providing a mechanism to use further custom *.ini files.

So, responsible developers could say:

• no time to do it
• do it, if it's works nice it will be integrated
• wontfix (e.g. as there's no interest to increase the flexibility of the core further)

I will add the missing flexibility anyway, the point is, if I do it with a dynapatch/own solution, or if I do it in a way that it can go to 0.11dev, thus other developers can benefit from it.

[Noah Kantrowitz (coderanger) <coderanger@…>]

This is not the way this community operates. Make the changes, submit a patch, and see if someone will look at it. End of story. This is pretty common in the FOSS world, and I would think someone of your "experience" should know this. If you dislike this methodology, fine, but take that discussion elsewhere.

[ilias@…]

Replying to Noah Kantrowitz (coderanger) <coderanger@yahoo.com>:

This is not the way this community operates. Make the changes, submit a patch, and see if someone will look at it. End of story. This is pretty common in the FOSS world, and I would think someone of your "experience" should know this. If you dislike this methodology, fine, but take that discussion elsewhere.

Please have the gentleness to take your off-topic / off-tenor comments 'elsewhere' (which btw. are completely nonsense, in context of this ticket).

As for standard methodology:

I am asking here (within the public ticket system) for feedback, in order to avoid redundant effort and in order to produce something that don't misses relevant facts, implementation details, on-going work of core-developers etc.!

The reason is simple: 5 min. from someone experienced with the code can save me hours or even days.

This is nothing special, and I really don't understand why I have to justify/explain this.

I remind you that this ticket does not affect trivial functionality, but an extension to the core, so it would be nice to have some feedback for the further processing.

If I don't get feedback - that's fine, too (I am used to this, most of my tickets 'stuck').

as a sidenote: the most worthfull feedback within this ticket came from 'sid' (except he well meant suggestion to use ConfigParser? for an own ini file, which would be an unelegant solution)

[cboos]

In addition to all what has already been said, there's now also the [inherit] file = ... mechanism that can be used in order to use additional .ini files. See TracDev/ReleaseNotes/0.11#Setuptoolsisnowusedforthepackaging.