Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Refactor Configuration Hierarchies #153
In the engine-config branch (c4485af), I started moving around the canonical references to a number of attributes App::Sqitch::Engine, in trying to find an easy-ish way to resolve #151. Unfortunately, it turned out to be way more than I wanted to take on for the amount of time I had, mostly because App::Sqitch and App::Sqitch::Engine are now all up in each other's business---and I was going to end up with Plan affected, too!
I think this needs a pretty major re-think, instead. The current architecture is a result of the original implementation supporting only one configuration, engine, and plan, but now, especially with targets, we need to be able to support many plans and engines at once.
So I think we to re-organize things to better handle the hierarchy of options and configuration. The hierarchy is, essentially, for any given attributes, an appropriate value should be sought out in this order:
Not all attributes will need to search all these places, and some may not have reasonable defaults, so should die, instead. But in any event, I think there needs to be some sort of nexus for these sorts of lookups. It should have:
I think this ought to be a singleton object created for every run. Perhaps it could also handle the command-line options for specific commands, too. It would be the first thing created when the app starts. Perhaps
In this scenario, App::Sqitch itself just becomes the nexus for creating and dispatching objects, and ceases to be the place where options and configuration are handled. Maybe something like this:
So App::Sqitch::Core is the new singleton object I describe. It knows what the command is, loads it up and returns it, but the command has no reference to the core object itself (no circular references). The command can call
Or maybe App::Sqitch itself needs to be rewritten this way, with no ::Core. There are a lot of references back to App::Sqitch itself all over the place that would need to be ripped out. So maybe simpler would be to leave those, and instead have it not be a singleton, but just change its interface so that it no longer represents options and config in its attributes but just stores the option and config objects as attributes.
Yes, I think that's the way to go. Less work. Yes, it changes the interface of App::Sqitch quite a lot, but I doubt anyone will complain.
Some thoughts as I tried to go to sleep last night after writing this. Modify
Likely will require some fiddling, but the idea is to load the most specific stuff first, and continue with more general things. So always prefer to find attribute values following this hierarchy of configuration:
I think the Target object will contain the canonical locations for these things. It should be accessible via an attribute in the Sqitch object, as should Engine.
This was referenced
Oct 20, 2014
This is done with merge f972abd. I added a new Target class that splits out the engine and target configuration from Engine and Sqitch. It's a simple class, but since nearly every file touched App::Sqitch, it was a lot of work to refactor things. But it's a much better division of labor this way, and gets us excellent hierarchical configuration.