Modularize trac-admin

[Remy Blank]

All trac-admin commands are implemented in trac/admin/console.py. As suggested by Christian in comment:11:ticket:7723, it would be nice to modularize it by introducing an IAdminCommandProvider. The advantages would be:

• Make it easier to write commands.
• Allow plugins to add commands to trac-admin.
• Minimize code duplication for command parsing and auto-completion.
• Move code into the individual modules, where it belongs. This would also allow console and web admin modules to use common code.

I have started working on this, and the first patch below is a proposal for the interface, for the command manager, and the changes to be done for one set of commands (the config commands).

I don't think that it would be necessary to work on this in a branch, as the new interface can be introduced without breaking backward compatibility, and commands can be migrated to modules progressively.

Comments very welcome.

[Remy Blank]

Interface and command manager proposal, and working example for config commands

[osimons]

A good initiative - and much discussed over the years without much progress. Thanks for picking it up :-)

I haven't tried the patch yet, just read through it. I see that the interface only has one get method, and returns the method to call for each command. No doubt that works well, but it just feels slightly different to the usual way of interfaces that commonly have a get to 'register' and a process method to 'handle' the execution. I'm fine with either though.

[Remy Blank]

Replying to osimons:

A good initiative - and much discussed over the years without much progress.

I should have searched the trac-dev archives before starting. I'll do that later today, but if you have any pointers to interesting threads on the subject, I'm all ears.

I haven't tried the patch yet, just read through it. I see that the interface only has one get method, and returns the method to call for each command. No doubt that works well, but it just feels slightly different to the usual way of interfaces that commonly have a get to 'register' and a process method to 'handle' the execution.

The reason I prefer the former is that it doesn't require duplicating the dispatching code in every process method. It's also the model used for IWikiSyntaxProvider, IIRC.

Thanks for your comments!

[Remy Blank]

Updated patch also moving most of the ticket commands to ticket/admin.py

[Remy Blank]

Complete patch against trunk

[Remy Blank]

The patch above should be complete:

• All commands except help and initenv have been moved into individual modules. The latter is somewhat special, as there's no environment yet on execution, so it can't be placed into a Component. It could still be moved into a function in e.g. trac/env.py, if desired.

• All commands have been tested, with all combinations of optional arguments.

• Auto-completion for all commands has been tested.

At this point, I'm happy with the result. It would be great if I could get some review (and possibly some more testing) before I apply the patch.

In a second step, I'd like to add more unit tests, for the commands that are not yet tested.

[osimons]

Patch tested, and it works really well - at least for the handful of commands I tested. Auto-completions is really nice too :-)

The structure of the code also looks good. Reading through the patch it looks like the new providers are all implemented in the logical places in the code.

+1 on committing it. Well done!

[Remy Blank]

Thanks for the review. The patch has been committed in [7677].

I'll leave this ticket open as a reminder for me to add more unit tests for the various trac-admin commands.

[Remy Blank]

Adding more unit tests should actually be tracked in a new ticket. Closing this one, as it's done.