[melbourne-pug] config files? pfft!

Sam Watkins sam at nipl.net
Fri Mar 1 03:54:25 CET 2013


On Fri, Mar 01, 2013 at 12:39:41AM +1100, Jonathan Morgan wrote:
> Hi Sam,
> 
> Interesting point (and probably good for internal config).  Just a few
> questions (from what I use config files for - user accessible
> configuration):

> 1. How do you deal with syntax errors when the user modifies this file?

It would give a python traceback I suppose.  We could present the exception
more neatly if the users cannot understand a traceback.  Typical "users"
for my work are sysops, they can handle it.

For my purposes it's not worth to make it more complex by handling syntax
errors specially.

One might write a global error handler, to handle any exception, simplify
the message, and show it in a gui dialog or whatever.  That will be helpful
for the user to understand any error, not only configuration errors.

Here's an example with an error handler, it presents the error more clearly.

test.py:
	from conf_load import *
	print a

conf_load.py:
	import sys, traceback, re
	try:
        	from conf import *
	except: 
        	print "config file error:\n%s" % (re.sub(r'^[^\n]*', '', traceback.format_exc(limit=0)))
        	sys.exit(1)

conf.py:
	a=99z

output:
	config file error:

  	  File "/home/sam/conf.py", line 1
    	    a=99z
        	^
	SyntaxError: invalid syntax


This message from python is very clear and helpful, better than you're
likely to get from a config library.

> 2. Can a user inject undesirable code into the system and break my code /
> security / something?

Such users should not be allowed to edit config files!  It can only be
an extra security risk if your process runs with elevated privileges,
or your users have access only to the config file.  In that case, you
should get a trusted user to configure it!  Or generate the config file
safely, somehow.  I do not let random users edit my DNS or web server config,
or /etc/shadow, directly, even though these are "standard" config files.

My suggestion is meant to be a quick and easy way to configure scripts,
not a complex and difficult bloatware configuration framework!
This little discussion about it is already like 1000 times more code than
the technique itself.

> 3. Can you have a system with defaults and only set config that isn't the
> default value?

Yes, just import from the defaults file before you import from the config
file, or hard-code the defaults in the main program somehow, or import
from the defaults file at the start of the config file or config loader
module.  It's a good idea; makes it easier to upgrade packages when the
defaults change.

> Will you be able to change e.g. just one entry in a dictionary property?)

dict['foo'] = 99   # why not?

> These reasons would all drive me towards using a "standard" config file,

I didn't see any reason to prefer a "standard" config file.

Anyhow, if you don't like this way, you can use a config library.

As for me, I don't like needless complexity,
so I will continue with `from config import *`, `import config as c`,
and such.


Sam


More information about the melbourne-pug mailing list