These are the characteristics ofgit config, which we want to emulate inconda.

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

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

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

• Global: writes to~/.gitconfig

• Local: writes to the repository.git/config. If no file option is given togit 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 environmentvariables.

Git uses its own special syntax. Conda uses yaml. We should continue to useyaml, because it is really easy to read and write from it with theyamlmodule. 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, butmuch more extensive (items in each section do not need to be key valuepairs).

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 isexplicitly set in any of the config files. There are the following variantsof--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 aregular expression. There are some case sensitivity issues here (see thegitconfig manpage).

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

• replace: replace options. The option is called--replace-all. It replacesall options with the given key. You can also give a regular expression tomatch 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 ismore than one line.

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

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

Some other useful things

• --list: Lists all configuration items. They are output in a way that canbe input back togit config.

Git config has the following types of errors (from thegit 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.