[Twisted-Python] twisted server config: command line, environment or Axiom?
Eric P. Mangold
eric at teratorn.org
Wed Aug 8 12:31:42 EDT 2012
On Wed, Aug 08, 2012 at 03:58:27PM +0200, Laurens Van Houtven wrote:
> I have a bunch of configuration for my service. Things like endpoints, location of the root axiom store? Right now I grab these from the environment. That means that my twistd IServiceMaker plugin's options is pretty much by definition empty.
> I'm wondering if more mature twistd users have already learned the hard way what the best way to manage this is. I see three possible solutions:
> 1. environment variables as I use them now: portable, simple.
> 2. command line options: still pretty portable and simple. additional benefit: easy discoverability of options
Both, preferrably. Defining all of your configuration in terms of t.p.usage.Options is not a bad thing at all.
It's human readable, and scriptable. And it maps directly to ENV vars or INI files (etc). If you have strange configuration requirements, (like binary files), I think those belong in their own seperate file(s). E.g. SSL certificates, PW files, etc
> 3. axiom store: has the benefit that there's a single source of truth for everything, i.e. I copy a store and I can recreate the service based on that store exactly, using just the store
Yeah, I hate that kind of configuration. Configuration is/should-be diffable with standard tools, if possible.
> Like I said, I currently use (1), it looks like (1) and (2) are more or less equivalent, I'm not sure if (3) is a good idea. I'm not really unhappy with (1), it's just that finally writing my ServiceMaker class made me contemplate the options.
> (3) has the downside that it conflates user data with configuration data. I'm not sure that's a good thing or not. It sounds very similar to axiomatic, which I've heard of, seen, but never played with.
Well as indicated *I don't like it*, but really that is only due to lack of tooling support... :)
> I already use environment variables to decide whether or not to run certain tests ("live" functional high level tests, with real disk and network IO, that take way longer than the unit tests to run). I'm going to keep it that way, because there's no obvious way of passing configuration to the tests other than the environment.
Yeah. Plain ENV vars are probably the best bet there.
More information about the Twisted-Python