Advanced Configuration techniques?


Hi guys,

So I am getting to have a pretty respectable API built, but their is one thing still bugging me. Configuration. I am still sitting here with a settings dictionary in an file. I tried using a config.ini file and then a config parser, but that seems like a lot of work just to create a settings dictionary from single key value pairs. I am toying with the idea of just using a file, and writing a factory function that returns an App. Many different ways to skin this cat. Putting 12-15 environmental variables on my machine is also not really ideal. Especially when you run gunicorn you have to pass those in since the process doesn’t get access to the environment variables on the machine. Essentially I end up with the config just sitting in the app.service if I go that route.

I am also struggling with how to pass through configuration settings down to subpackages of my application. Right now the config file lives outside of a my application package and while the Settings component works for my annotated routes I can’t seem to access settings anywhere else due to model import errors. I am trying to set something like the number of bcrypt rounds in the settings instead of having them hard coded.

How are you guys handling configuration?


I’ve attacked this problem for various projects before, and was just approaching it today for my first APIstar project.

For Django I wrote django-classy-settings which lets you use classes to declare and inherit dynamic configs, including supporting env vvars.

For my own PAWS tools, I wrote a quick, simple singleton class that tries to resolve attributes through the environment, and allows you to declare fallback defaults.

I think for API* I like the idea of extending that to permit dict access…

I’m unclear of how gunicorn could be isolating your process from the environ… got any links about that?

Do you think this might help with any of your issues? What else could help?


It was with much grief that I finally learned that Gunicorn creates it’s own scope for environmental variables. I guess it makes sense if you are running multiple web apps on the same server, you don’t want name space collision like if two web applications used an extension requiring the same environmental variable name.

Really my issue is that I want a generic application with many different locations (outside of apistar’s dependency managed functions aka views/components) where I can access the settings that the instance of my App was created with.

A perfect example is the number of bcrypt log rounds that a user’s password should be hashed under. Right now I have an .ini file that has these one offs in them, but I am used to Flask where the Flask app instance stores the application config, but is also importable into sub packages of your application allowing for access and configuration of your application, not just in your view functions view Settings component dependency injection.

Here is where I got hackey but failed:

I tried using setattr(app, 'settings', {<settings dict>}) then using get_current_app() to kind of recreate that same behavior. Only problem is that the _current_app isn’t set at that time and looking at the get_current_app() implementation it’s tightly coupled to the idea of an app variable defined in an module located in the current working directory. That’s not how I create my applications though I use something like this:

Where I have a that is responsible for importing a factory function and taking a config file and returning an application instance to the WSGI server. The settings are in the as a dictionary. This keeps everything nice and neat. Also easy to deploy.