#267 figure out module scheme for taskotron modules
Closed: Fixed None Opened 8 years ago by tflink.

If we're going to split off all non-core functionality into modules, we need to have a way of loading those modules.

Evaluate methods of having modules and determine which one will work best for us looking at side-effects, amount of work and other drawbacks in addition to the benefits that scheme would bring.


This ticket had assigned some Differential requests:
D616

my first thought is to look at how flask manages extensions and attempt to copy that scheme but I haven't gotten very deep into how well that might work for us.

another thing to take into consideration is how this modularization will affect directives.

If you are controlling the loading of the modules from a central configuration file, I would think that not much else would change, other than APIs wouldn't exist when the modules aren't loaded. I suppose the main thing is to have a way for directives/scripts to declare what modules from taskotron are needed for them to function. If they aren't there, it should be able to fail gracefully.

This was first fixed with D616, it's not perfect but is a lot better than it was.

More tweaks will be needed before all the fedora and rpm-isms are out of core, but that can be handled in a different task

Login to comment on this ticket.

Metadata