These are the characteristics of git config, which we want to emulate in conda.

git help config has all the information. http://git-scm.com/book/ch1-5.html is also a good reference.

git has three different locations that a config file can be. The most local version take precedence.

• System: writes to /etc/gitconfig ($(prefix) is generally nothing).

• Global: writes to ~/.gitconfig

• Local: writes to the repository .git/config. If no file option is given to git config, --local is the default.

(these locations are a little different on Windows)

There is also a --file option which can write to any file.

For conda, these could correspond to

• System: Is it still useful to have a system-wide configuration? It may be, so that sysadmins can easily deploy channels.

• Global: This corresponds to ~/.condarc. I'm not a huge fan of the word "global", but maybe there's a good reason for it.

• Local: This might correspond to environment specific configuration.

We also might want separate configuration for the different app types.

Right now, we also allow to configure certain things with environment variables.

Git uses its own special syntax. Conda uses yaml. We should continue to use yaml, because it is really easy to read and write from it with the yaml module. Git's format consists of sections with one or more key value pairs (the same key can be duplicated in the same section). yaml is similar, but much more extensive (items in each section do not need to be key value pairs).

There are four basic operations in the git configuration system.

• query: Read the value of the option. In git config, this is called --get. This also gives the default if no configuration option is explicitly set in any of the config files. There are the following variants of --get:

  • --get: get a single value for a key. Errors if there is not exactly one value.
  • --get-all: get multiple values for a key.
  • --get-regexp: same as --get-all, but interprets the input as a regular expression. There are some case sensitivity issues here (see the gitconfig manpage).

• set: This adds a new option without altering existing ones. The option is called --add. One thing that does not seem to be handled is the difference between prepending an option and appending it, which can matter in conda for things like channels where the order matters.

• replace: replace options. The option is called --replace-all. It replaces all options with the given key. You can also give a regular expression to match the value against, and only those values will be replaced.

• unset: deletes the key. There is --unset, which removes one line, and --unset-all, which removes all lines. --unset does not work if there is more than one line.

In git, the sections are organized categorically, like core, diff, http, gui, etc. The current conda sections (channels and environments) actually correspond to the keys in the git system.

In conda, we will not have sections (at least for now). The key value pairs in the conda system will correspond to the section header being the key, and the items under the section being the value.

Some other useful things

• --list: Lists all configuration items. They are output in a way that can be input back to git config.

Git config has the following types of errors (from the git help config manpage):

1. The config file is invalid (ret=3),

2. can not write to the config file (ret=4),

3. no section or name was provided (ret=2),

4. the section or key is invalid (ret=1),

5. you try to unset an option which does not exist (ret=5),

6. you try to unset/set an option for which multiple lines match (ret=5), or

7. you try to use an invalid regexp (ret=6).

On success, the command returns the exit code 0.

http://www.infoq.com/articles/5-config-mgmt-best-practices is a good read.