Configuration sections from plugins should be written to trac.ini

[Ryan J Ollos]

When a Trac environment is first created the default data is written to trac.ini​. However, when installing a plugin the default data is not written to trac.ini.

When the plugin enabled it would be nice to have the default data added to trac.ini. Currently the user must manually type the section and option name if they wish to change any configuration values. I think that most users would expect that the defaults for all configuration values be found in trac.ini.

A quick implementation that is not ideal, but demonstrates the idea is found in log:rjollos.git:t11437.

One issue with the quick implementation is that all of defaults are written to trac.ini, not just those of the plugin being installed. Maybe this is okay, but if a user likes to remove a lot default options to simplify the file, they may be surprised to have their changes undone (#7378).

#8290 had me thinking of a different solution, that plugins could add the information through existing IEnvironmentParticipant method, or new methods or helper functions that we add. The downside of course is that every plugin then needs to be modified to implement the behavior.

Side note: it might be useful to have a trac-admin $ENV config clean command to remove options from trac.ini that are no longer defined in an enabled Component. For example, with ​th:AccountManagerPlugin, many options were renamed going from 0.3 → 0.5, and the users must manually clean up these sections. This comes up rather frequently when users post their configuration to tickets and it contains a mess of old and new configuration options. Of course, it causes no harm to leave them, it is just more confusing and error prone to manage the trac.ini file. We could, by default, create a backup of the trac.ini file whenever clean is run.

[Jun Omae]

A quick implementation that is not ideal, but demonstrates the idea is found in log:rjollos.git:t11437.

Another PoC: jomae.git@t11437.1.

[Ryan J Ollos]

The changes in comment:1 look good to me. I'm testing them along with the changes in #11520 and I'll make some comments in that ticket.

[anonymous]

FWIW, Please keep in mind the use of the "global configuration". I use this extensively, and I keep most settings in the global configuration file.

For instance, if updating some setting in a Trac instance introduced a lot of other kinds of settings into the local configuration file, it could be then necessary to clean out all the defaults overriding the global configuration.

(I mainly mention this due to the comment about writing all defaults to trac.ini, not just those of the plugin being installed.)

[Ryan J Ollos]

The latest changes after #11520 can be found in log:rjollos.git:t11437.2. However, I plan to do more work before committing.

[S.N.Maijers@…]

I am not convinced of the usefulness of this. What happens if the configuration format for a plugin changes? Why would an administrator expect default options to be explicitly in the Trac configuration? The current system, where the administrator may set/override (default) configuration options works fine and is more robust in my opinion.

[Ryan J Ollos]

Replying to S.N.Maijers@…:

What happens if the configuration format for a plugin changes?

The same thing that would happen if the option has been added by editing the config file. The extra entries would be harmless and are the use case for the config clean command that I describe in comment:description.

Why would an administrator expect default options to be explicitly in the Trac configuration?

Less typing, less possibility of mistakes in entering the option name and less need to look up what options are available in the documentation. Every default option for Trac is written to the config file, so adding plugin defaults would be consistent.

The current system, where the administrator may set/override (default) configuration options works fine and is more robust in my opinion.

You've not made an argument for why the change would not be robust.

[jholg@…]

Replying to anonymous:

FWIW, Please keep in mind the use of the "global configuration". I use this extensively, and I keep most settings in the global configuration file.

+1 Please take into account multi-project trac installations where

• there's one "master" project and all the "slave" projects inherit its global configuration, overriding only those config options that differ
• plugins are installed globally i.e. the Python installation or virtualenv used for running Trac, not in a project's plugins dir

Changes introduced with this ticket should not lead to writing defaults to "slave" trac.ini files

[Ryan J Ollos]

Proposed changes in log:rjollos.git:t11437.4. The following behaviors have been implemented:

• When a plugin is enabled through TracAdmin or the Web administration page, the component options are written to trac.ini if they don't already exists in trac.ini or a parent configuration.
• The # option-name = <inherited> markers are no longer written to trac.ini, but still if the value is defined in a parent configuration, the default value is not written to trac.ini when enabling a component or creating an environment.