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
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

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.

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.

cheers
lvh




_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Reply via email to