Configuration section disabled_components uses negative logic

[trac@…]

The [disabled_components] section of trac.ini uses the form:

[disabled_components]
trac.versioncontrol.web_ui = yes

It may be cleaner, especially for non-native English speakers, to use disabled, rather than yes, as the value indicating that a component should be disabled. In general, asking negative questions should be avoided, am I wrong? </example>

This should be a trivial change/fix with a small, but tangible benefit.

[eblot]

+1

In such a case, I think the section title would be better changed as well, e.g.

[core_components]
trac.versioncontrol.web_ui = disabled

[cmlenz]

The list isn't only about core components, it's about any component, also those provided by plugins.

Say I installed some plugin that provides some feature I don't want, nicely tucked away into a component. I can disable that component to get rid of the unwanted feature, just as I can disable a component that comes with Trac.

Maybe it'd be better if any component listed under [disabled_components] would be treated as disabled, regardless of value. But I think that'd actually be more confusing than the current solution.

[eblot]

So why simply not:

[components]
trac.versioncontrol.web_ui = disabled
custom.plugin.extension = disabled

disabled or off, no, and any boolean value that evaluate to false as defined in util.py

[trac@…]

I'm of the mindset that it is best to include the actual desired state in the value specified. That is, enabled/disabled or on/off should be the only accepted values. This indicates the desire without referencing the stateful intention of the section. Maybe these are minor semantics, but I like to know what is happening on a given line without having to ask whether yes means enabled or disabled.

I'm also a big fan of extending the section to the larger general component scope for the exact reasons you mention.

As a note, especially when setting up and testing, I like to adjust my configs by doing things like this, where switching consists of commenting the alternate line:

[components]
#some.extension.being.tested = enabled
some.extension.being.tested = disabled
some.alternative.extension = enabled
#some.alternative.extension = disabled

[cmlenz]

I've implemented the following approach here:

Given a trac.ini containing:

[components]
trac.ticket.web_ui.UpdateDetailsForTimeline = false
trac.versioncontrol.* = false
webadmin.* = true

Would enable all the core components except for the explicitly disabled trac.ticket.web_ui.UpdateDetailsForTimeline and everything in the trac.versioncontrol package. In addition, it would enable every component in the webadmin package.

Note that trac.* = true is implicit in the configuration.

[trac@…]

I love it. The wildcards should be very handy.

[cmlenz]

I've missed your previous comment, but I do actually agree on using proper value names. My current implementation interprets both “enabled” and “on” as legal values for enabling a component. Anything else is considers to disable the component.

About the wildcards, they only work at the end of the string. I figured that was the only place they would actually make sense in practice. But by actually requiring the wildcard at the end to do name-prefix matching, the meaning of those options becomes a lot clearer than by just doing the prefix matching implicitly (as it is now).

[cmlenz]

Implemented in [2335].