On Wed, Aug 08, 2012 at 03:58:27PM +0200, Laurens Van Houtven wrote:
> Hi,
>
> 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.
--
Cheers,
-E
_______________________________________________
Twisted-Python mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
