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

Cant find settings when running the program from another folder than root folder #74

Open
jgiudici opened this Issue Jul 18, 2018 · 8 comments

Comments

Projects
None yet
3 participants
@jgiudici

jgiudici commented Jul 18, 2018

Hi, I have this folder structure:


test_dynaconf
└── subfolder
    ├── main.py
    └── settings.toml

with main.py:

#main.py
from dynaconf import settings

print(settings["KEY1"])

and settings.toml:

#settings.toml
[default]
KEY1="hi"

If I run from subfolder, everything works:

➜  subfolder python3 main.py 
hi

But if I run from test_dynaconf or another path, it breaks:

test_dynaconf python3 subfolder/main.py
Traceback (most recent call last):
  File "subfolder/main.py", line 3, in <module>
    print(settings["KEY1"])
  File "/usr/local/lib/python3.5/dist-packages/dynaconf/utils/functional.py", line 208, in inner
    return func(self._wrapped, *args)
  File "/usr/local/lib/python3.5/dist-packages/dynaconf/base.py", line 193, in __getitem__
    raise KeyError('{0} does not exists'.format(item))
KeyError: 'KEY1 does not exists'
@rochacbruno

This comment has been minimized.

Show comment
Hide comment
@rochacbruno

rochacbruno Jul 18, 2018

Owner

Hi, this is the expected behavior.

Dynaconf can look back on the directory tree and try to find settings files in parent folders, but it does not do the reverse which is looking for settings files in child folders.

If your use case demands to store settings in a different location you can do:

export SETTINGS_MODULE_FOR_DYNACONF=/path/to/location/settings.toml

We can think of adding the look for settings file in the same folder as the running script as a fallback but I dont know if this will be a good idea.

Owner

rochacbruno commented Jul 18, 2018

Hi, this is the expected behavior.

Dynaconf can look back on the directory tree and try to find settings files in parent folders, but it does not do the reverse which is looking for settings files in child folders.

If your use case demands to store settings in a different location you can do:

export SETTINGS_MODULE_FOR_DYNACONF=/path/to/location/settings.toml

We can think of adding the look for settings file in the same folder as the running script as a fallback but I dont know if this will be a good idea.

@rochacbruno

This comment has been minimized.

Show comment
Hide comment
@rochacbruno

rochacbruno Jul 18, 2018

Owner

If you think it is valid to look for subfolders, please give me some time to try the implementation, I want do get some feedback about it before implementing.

Owner

rochacbruno commented Jul 18, 2018

If you think it is valid to look for subfolders, please give me some time to try the implementation, I want do get some feedback about it before implementing.

@jgiudici

This comment has been minimized.

Show comment
Hide comment
@jgiudici

jgiudici Jul 18, 2018

The issue arises when I've tried to deamonize a script from supervisord, I've already resolved it with a config option of supervisord, but I think it has sense in the meaning that a script shouldn't be dependent of the pwd that was invoked if the script doesn't explicitly use a relative path to config.

jgiudici commented Jul 18, 2018

The issue arises when I've tried to deamonize a script from supervisord, I've already resolved it with a config option of supervisord, but I think it has sense in the meaning that a script shouldn't be dependent of the pwd that was invoked if the script doesn't explicitly use a relative path to config.

@jgiudici

This comment has been minimized.

Show comment
Hide comment
@jgiudici

jgiudici Jul 18, 2018

Maybe the search for the settings file must begging on the dir of the called script and not pwd?

jgiudici commented Jul 18, 2018

Maybe the search for the settings file must begging on the dir of the called script and not pwd?

@rochacbruno

This comment has been minimized.

Show comment
Hide comment
@rochacbruno

rochacbruno Jul 18, 2018

Owner

@jgiudici I'll make some tests, try to figure out scenarios where this can lead to errors and expect for more comments then maybe we can change it. I have also to check if it is easy to get dynamically the path for the called script.

Owner

rochacbruno commented Jul 18, 2018

@jgiudici I'll make some tests, try to figure out scenarios where this can lead to errors and expect for more comments then maybe we can change it. I have also to check if it is easy to get dynamically the path for the called script.

@brucegibbins

This comment has been minimized.

Show comment
Hide comment
@brucegibbins

brucegibbins Sep 10, 2018

Hi. I am new to your package and I have recently introduced it to a colleague. The first question he had was if he can store the settings.yml in a sub-folder. We typically have a similar structure to the following where configuration settings are kept in a yaml file in a folder off the root of the package.

.
+-- app.py
+-- conf
|   +-- settings.yml
|   +-- other.yml  (just as a sample)
+-- util
|   +-- file1.py
|   +-- file2.py
.

I too usually have this structure but simply moved my settings.yml to the same level as the app and thus benefited from the default behavior. We are a windows shop and could of course use the EXPORT environment variable equivalent at runtime but in my opinion it would be certainly beneficial to us if we could keep the configuration settings in a subfolder as an option.

brucegibbins commented Sep 10, 2018

Hi. I am new to your package and I have recently introduced it to a colleague. The first question he had was if he can store the settings.yml in a sub-folder. We typically have a similar structure to the following where configuration settings are kept in a yaml file in a folder off the root of the package.

.
+-- app.py
+-- conf
|   +-- settings.yml
|   +-- other.yml  (just as a sample)
+-- util
|   +-- file1.py
|   +-- file2.py
.

I too usually have this structure but simply moved my settings.yml to the same level as the app and thus benefited from the default behavior. We are a windows shop and could of course use the EXPORT environment variable equivalent at runtime but in my opinion it would be certainly beneficial to us if we could keep the configuration settings in a subfolder as an option.

@rochacbruno

This comment has been minimized.

Show comment
Hide comment
@rochacbruno

rochacbruno Sep 10, 2018

Owner

I want o implement those changes without breaking backwards compatibility with existing use cases.

For that I need to figure out 2 things:

  1. How to get the path the script has been called (instead its pwd) including the django and flask cases.

  2. to have a default folder name, I would call it by default 'dynaconf/' , 'conf/' or 'settings/' I would default to a folder called settings but not sure if it can break existing projects already using that folder name.

Owner

rochacbruno commented Sep 10, 2018

I want o implement those changes without breaking backwards compatibility with existing use cases.

For that I need to figure out 2 things:

  1. How to get the path the script has been called (instead its pwd) including the django and flask cases.

  2. to have a default folder name, I would call it by default 'dynaconf/' , 'conf/' or 'settings/' I would default to a folder called settings but not sure if it can break existing projects already using that folder name.

@brucegibbins

This comment has been minimized.

Show comment
Hide comment
@brucegibbins

brucegibbins Sep 10, 2018

brucegibbins commented Sep 10, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment