So my project management software has a new alpha release. Originally this version was just going to have a few small features that a friend needed for his use-cases that required changes to core functionality (his front-end doesn’t require anything akin to a configure step).

The specific features I wanted to support for 0.3.0 were:

• Support generic configuration access. All the tooling (including core stuff that everything else depends on) is tightly coupled to the idea of a cached configuration that’s little more than the base configuration with some extra key/value settings. This works great for my use cases, but for my friend’s case (which is effectively a list of repositories to manage), the configure step is useless. Now, the internals require some sort of configuration object, but tooling can specify how to get those objects via a function.
• Perform sanity-checking on configurations. A common problem he (and in fairness, I) run into is an extra comma in a list that makes things break. By providing hooks for plugins to register sanitizers, now we can check these values earlier and tip the end-user off.
  

The latter option has been on my bucket list for a while, but the first one is what led me down a refactoring path. In what should be a surprise to nobody, there was a fair bit of code in dev-pipeline that was coupled to the configparser types. To support the first point, I had to update all of them to use a new interface, but that got me thinkng: would it be useful to have tooling that can easily query a project?

Maybe I’m old school, but when I want to see relationships my mind goes straight to databases. With the generic interfaces in use now, using a sqlite database becomes much simpler. I could even leave my comfort zone and explore one of those fancy NoSQL dataabses, since now the internals are indifferent.

The other thing though, and what could be very interesting to explore, is that there’s no dependency on an ini-style configuration now. Somebody could provide a configure-like command that uses a JSON or XML file; I don’t see the benefit either provides over ini files, but JSON is all the fad these days and XML refuses to die.

Here’s a more interesting idea though: supporting some sort of programmatic tool to provide the configuration. Now I’m a believer that build configurations should be more declarative than programmatic, but there are definitely cases where being able to run a Python (or ruby, or shell, or X) script is cleaner than stuffing things into build.config. With the entire concept of configurations being abstracted away, this becomes a feasible feature.

As a practical example, one of my personal issues with dev-pipeline was dealing with build artifacts whose location could differ (specifically related to cmake configuration that install under lib/lib64). For now I’ve been hardcoding the full path (with a bit of value interpolation), but that’s not remotely portable. There’s a better method to solve this in the new alpha release, but this is a natural place where executing a python script a build time would come in handy.

Does this mean I’m going to start working on a script-based project configuration tool? Not a chance, at least not for a long time, but it feels good to know the possibility is there. By adding a pretty minor feature, the doors are blown open for possibilities, which means dev-pipeline can eventually support a broader swath of projects.