RFC: Add support for config-files in etc-directories via dynaconf-xdg plugin

[woutervh]

Usually I create a virtualenv for my python-applications,
and I collect all config-files in an etc-directory to avoid polluting the project-directory, like this:

/opt/application-name/bin
/opt/application-name/etc/
/opt/application-name/lib
/opt/application-name/src/git-checkout

So I propose to look for config-files not only in the parent-directories, walking all the way up to root,
but also check the existence for an etc-subdirectory.

In bigger projects with lots of components, we split up the etc-dir into
.../etc/uwsgi
.../etc/supervisord
.../etc/dynaconf

As bonus we also support the global etc-directory:
/etc/settings.yml
/etc/dynaconf/settings.yml

[rochacbruno]

Great idea!

I would also include the XDR home ~/.config/dynaconf/

My only concern is when having multiple applications using dynaconf, lets say app1 and app2 each with specific configurations, dynaconf should know where to look for settings.

One options is appending in the path /etc/dynaconf/app1/ but for this DYNACONF_PROJECT_NAME must be informed as environment variable somewhere.

[rochacbruno]

another note is that currently this is already supported

You can explicitly do export DYNACONF_SETTINGS_MODULE=/etc/foo.yml and then Dynaconf will read the settings from that value.

DYNACONF_SETTINGS_MODULE=/etc/foo.yml,~/.virtualenvs/env/bin/python,program.py

It is not straightforward, you need to specify the path explicitly but works.

If there is a way for Dynaconf to figure out the application name and use as a path then we can avoid extra env vars.

[rochacbruno]

I am thinking about this one, and looks too risky to implement by default.

This should be an option explicitly set by user as export PROJECTNAME_FOR_DYNACONF=name and then dynaconf gonna look to ~/.name , ~/.config/name, /etc/name/ etc...

[sirex]

As far as I understand PROJECT_ROOT_FOR_DYNACONF=/etc should instruct dynaconf to look in /etc. I tried that, but it does not work. Is that a bug?

[rochacbruno]

@sirex being tracked on #106

[sirex]

Regarding etc directories. I think, there is a need to have a separate configuration for dynaconf itself and separate configurations for apps.

This might be related to #108. At least how I use dynaconf is that first I want to customize dynaconf behavior first. Currently I do that by creating my own customized LazySettings instance. But that only works from my app. Other customizations must be done via environment variables.

So maybe it would be a good idea to have a separate configuration file for dynaconf itself? Search locations could follow xdg basedir-spec.

Example /etc/dynaconf.toml:

[dynaconf.global.default]
merge_enabled = true

[dynaconf.app1.default]
project_root = "/etc/app1"
global_env = "app1"

[dynaconf.app1.development]
project_root = "{cwd}"

[chobeat]

@sirex I'm facing the same problem. I also checked in the code and the usage of the variable doesn't seem to relate to anything connected to file discovery. It always uses the os.getcwd()

[rochacbruno]

Thi issue is being resolved on #143

[rochacbruno]

That is decided that this feature will be added as a plugin once #146 is implemented

Then, to implement this user will have to:

$ pip install dynaconf
$ pip install dynaconf-xdg

When that plugin is installed, then dynaconf will read XDG compliant config like:

~/.dynaconf/conf.toml
~/.config/dynaconf/conf.toml
/etc/dynaconf/conf.toml

The above will be dynaconf general settings like @sirex suggested.

[dynaconf]
enable_x = true

Each application (app1 as example) then can drop files under

~/.dynaconf/app1/settings.toml
~/.config/dynaconf/app1/settings.yaml
/etc/dynaconf/app1/.secrets.json

If plugin is simply installed, this is included to search tree

The name app1 needs to be discovered by dynaconf, or via envvar APP_NAME_FOR_DYNACONF=app1 on that app env or via regex matching discovery based on inspect.stack() file name from where dynaconf has been loaded.

[rochacbruno]

Now Dynaconf has changed and it is required to pass explicitly the location for the config files to be loaded. https://www.dynaconf.com/#using-python-only

So the user is responsible for passing the value for XDG and this is not controlled by dynaconf.

from xdg import XDG_CONFIG_HOME

settings = Dynaconf(
    settings_file=os.path.join(XDG_CONFIG_HOME, "myfile.yaml|toml|ini|json|py")
)