configuration from the filesystem

[thejohnfreeman]

In the documentation, Confit mentions taking configurations from directories. I'm guessing that means it expects a file of a prescribed name in those directories. I would rather just have a function that takes a path and returns a configuration that I can pass to override (#9). Then, composing a colon-separated path of configuration files in precedence order turns into this:

reduce(confit.override, map(confit.from_file, PATH.split(':')))

I think there is a good opportunity for directory based configuration, though. Many projects (like the users of this other confit) want to use different sets of defaults based on different environments. Common environments include "development", "qa" or "staging", and "production". It would be convenient if they could have a directory of multiple configuration files named after the environments.

def from_file(env, path): # env comes first for partial application
  file = path
  if not file.is_file():
    file = path / env
  if not file.is_file():
    file = path / (env + '.yml')
  ... # more guesses
  with open(file, 'r') as stream:
    return yaml.load(stream.read())

[sampsyo]

Yes, all good points.

The main reason that directories showed up before files in Confit is because, for my use case, I needed a way to store other files alongside the configuration. That is, in beets, the configuration really consists of a whole directory, not just the YAML file itself.

That said, I realize that the common case is probably a single file. Supporting a whole directory would be a nice extra feature, but the primitive functionality should be more or less as you've described it.

Nice find on that other confit. It does seem like this kind of environment-based configuration could be easily implemented by overlaid named configurations—separate functionality could provide the name-based search in the filesystem.

[thejohnfreeman]

As a general practice, I would encourage authors to always use a single configuration file, keeping in mind a distinction between configuration and data. Many popular tools follow this pattern. For example, Git and Mercurial have .git/config and .hg/hgrc, respectively, and the rest of the contents of their hidden directories is all data. npm and Bower have package.json and bower.json and the rest of the contents of the package directories (source code, tests, docs, etc) is all treated as data. Just a note that influenced my last design.

That said, though, I think the directory approach with environments generalizes. In that perspective, a project with a single config file is just the special case that has exactly one environment.

[sampsyo]

Indeed—and beets works exactly the same as git and hg (those other files are data, not configuration).