Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
WouterVH opened this issue Jun 30, 2018 · 10 comments
Closed

Comments

@WouterVH
Copy link

@WouterVH WouterVH commented Jun 30, 2018

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
Copy link
Owner

@rochacbruno rochacbruno commented Jul 1, 2018

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
Copy link
Owner

@rochacbruno rochacbruno commented Jul 1, 2018

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
Copy link
Owner

@rochacbruno rochacbruno commented Sep 10, 2018

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...

@rochacbruno rochacbruno changed the title Add support for config-files in etc-directories RFC: Add support for config-files in etc-directories Sep 21, 2018
@sirex
Copy link
Contributor

@sirex sirex commented Nov 7, 2018

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
Copy link
Owner

@rochacbruno rochacbruno commented Nov 7, 2018

@sirex being tracked on #106

@sirex
Copy link
Contributor

@sirex sirex commented Nov 8, 2018

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
Copy link
Contributor

@chobeat chobeat commented Jan 10, 2019

@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
Copy link
Owner

@rochacbruno rochacbruno commented Apr 5, 2019

Thi issue is being resolved on #143

@rochacbruno rochacbruno added this to the 2.0.0 milestone Apr 5, 2019
@rochacbruno
Copy link
Owner

@rochacbruno rochacbruno commented Apr 7, 2019

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 rochacbruno modified the milestones: 2.0.0, 3.0.0 Apr 7, 2019
@rochacbruno rochacbruno changed the title RFC: Add support for config-files in etc-directories RFC: Add support for config-files in etc-directories via `dynaconf-xdg plugin` Apr 7, 2019
@rochacbruno
Copy link
Owner

@rochacbruno rochacbruno commented Sep 12, 2020

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")
)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.