Thanks for this module , super useful quickly making configs.

So nothing is broken just getting deprecation warnings when running code under pytest. I get the following:

PendingDeprecationWarning: safe_load will be removed, use

yaml=YAML(typ='safe', pure=True) yaml.load(...)

Maybe can do setup based based on ruamel version ? Details in project description: https://pypi.org/project/ruamel.yaml/

Also unrelated, if none of the "default_files" are found there is no error and FileNotFoundError is not thrown, is that intended ?

Pydantic is widely used and does much of what this lib was doing. The maintainer has explicitly stated they are not interested in file loading. The other parts that still remain in Goodconf are generating configuration files and the markdown documentation.

Hi, thanks for goodconf!

In the example in the docs a Config object is initialised and assigned to a variable config. However the load method returns nothing. Therefore the config var is None.

Also in the modified manage.py I had to include this line for it to work normally:

if __name__ == '__main__':
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'main.settings')
    settings.config.django_manage()

Whenever I import Goodconf I get the next mypy error:

Skipping analyzing "goodconf": found module but no type hints or library stubs

It would be nice if goodconf exposed the typing information at package level, probably adding the py.typed file would be enough

Pydantic is widely used and does much of what this lib was doing. The maintainer has explicitly stated they are not interested in file loading. The other parts that still remain in Goodconf are generating configuration files and the markdown documentation.

Thanks for this solid tool! I wonder if we can take it further to meet my madcap schemes!

Or maybe this is already possible but I just haven't understood yet.

Here's my idealised solution:

Firstly, no need for two files: conf.py goes away and settings.py remains. I preferably only want to look at a single file for all the configuration declarations (goodconf actually makes it feasible to have this file declarative, short and easy to grok, woot woot).

Then, in my project-name/settings.py, I define (names not fixed, bikeshed as necessary):

from goodconf import GoodConf, generate_settings

class Base(GoodConf): # django core settings ...
class Dev(Base): # my dev specific settings ...
class Stage(Base): # my staging specific settings ...
class Prod(Base): # my production specific settings

generate_settings(  # `GoodConf` API more or less
    load=True,
    file_env_var='DJANGO_GOODCONF',
    default_class=Dev,
    settings_directory='./settings/',
)

So,

• If no DJANGO_GOODCONF is supplied, we generate a settings/dev.yml
• If DJANGO_GOODCONF=Stage, we generate a settings/stage.yml
• We load the settings/<ENV>.yml and programmatically make all settings available for Django (no need to X = config.X boilerplate) through some globals trick or something

The reason we need generate_settings (or something that isn't an environment specific subclass of GoodConf, like, Dev) is so that we can put the logic for the selection of the environment and generation of settings into goodconf core and not leave it for the user to configure. The DJANGO_GOODCONF env var is the only thing the user needs to consider when deploying to anything that isn't the localhost (Dev used by default otherwise).

Thoughts? Happy to get stuck in on implementation if we're in agreement!

PS. A lot of this comes from my past experiences with https://github.com/jazzband/django-configurations. I think if we join these two approaches, we have a really flexible method for Django configuration.

This is more of the "pydantic way" to do things and restores some functionality that was broken from the BaseSettings class (see #10 and #9)

It is a backwards incompatible change. The class is now validated on instantiation. The load method has been removed and a class method from_file has been added.

• [ ] update docs
• [ ] update changelog
• [ ] make new major release

Right now we can only load the settings, but it would be nice to have a save method to save changed configuration values. It should keep the user comments on the file

Hi, I'm trying to use the BaseSettings env_prefix Config property to preprend a string on the environment variables without success. A simple snippet that shows the desired behaviour is:

import os

from goodconf import GoodConf


class AppConfig(GoodConf):
    "Configuration for My App"
    DEBUG: bool = False

    class Config:
        env_previx = "GOOD_"


os.environ["GOOD_DEBUG"] = "True"

config = AppConfig(load=True)

assert config.DEBUG

Using os.environ['DEBUG'] = "True" works though

Hi, first thanks for your awesome project :)

To build the test cases, I want to create a GoodConf instance with some values that are different from the default, for example the DATABASE_URL attribute. It will be nice that we could do something like:

AppConfig(DATABASE_URL='fake://address')

I know BaseSettings from pydantic supports it, so maybe we can call to super().__init__ in the GoodConf``init`. What do you think?