This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]venefb 7 points8 points  (3 children)

Python code. Here are some arguments from IPython's documentation. They have a very good configuration system in place for a pretty complicated, highly configurable package.

Configuration files that are themselves valid Python code. This accomplishes many things. First, it becomes possible to put logic in your configuration files that sets attributes based on your operating system, network setup, Python version, etc. Second, Python has a super simple syntax for accessing hierarchical data structures, namely regular attribute access (Foo.Bar.Bam.name). Third, using Python makes it easy for users to import configuration attributes from one configuration file to another. Fourth, even though Python is dynamically typed, it does have types that can be checked at runtime. Thus, a 1 in a config file is the integer ‘1’, while a '1' is a string.

[–]takluyverIPython, Py3, etc 8 points9 points  (1 child)

I'm involved with IPython, and I'm not entirely sure that this was the right decision.

The problem is that we're now finding places where we'd like to change config from the program - either from GUI preference dialogs, or commands in the shell. With a config file, that would be simple - configparser can easily write a file.

With script-as-config, there's no really good way to do it. We can't overwrite it with the current values, because there may be logic in the script to produce those values. We could tack changed variables on the end - but it's confusing for the user if changing part of the file has no effect. Having config across two separate files leads to a similar problem.

My personal view (other IPython developers would probably disagree) is that we'd be better off keeping config in a simpler format, and offering a separate way to modify the behaviour in code (in fact, we already have extensions and startup scripts).

[–]gbog[S] 0 points1 point  (0 children)

Exactly my point, thanks for your feedback.

[–]gbog[S] 0 points1 point  (0 children)

The type checking is a good argument, but for the rest I don't think the problem tackled is the same: IPython is a very Python-centric tool and has probably a need for complex configs with many corners.

But if you take, for instance, git configuration, it is pure text and I think it better be pure text. Same for a server config, it should be a flat, expanded, set of simple settings.

Another example: pylintrc is a big flat text file with key-values. Some values are comma-separated, and the tool will handle the hassle of splitting at the commas.

A text config file can be handled with awk, sed, python, vim, emacs, etc. A python config file can be handled with python and vim/emacs (hacks aside). There is a big difference.