search

mbr / flask-appconfig

Configures Flask applications in a canonical way. Also auto-configures Heroku. Aims to standardize configuration.
http://pypi.python.org/pypi/flask-appconfig
MIT License
84 stars 15 forks source link

Slightly more unix-like way of loading config files #2

Open Fiedzia opened 10 years ago

mbr commented 10 years ago

I can definitely see where you're coming from there, however I cannot just merge this yet, as I'd like to think about that some more.

There is a use, especially when packaging apps in a Linux distribution's package and having system-wide defaults that can be overridden. However, here are some issues I have with it:

  1. I'm reluctant to make a change in core behavior, as consistency is a huge priority for Flask-Appconfig, as you can imagine.
  2. I don't like introducing new conventions that may clash with others. For example, it's unclear if ~/.appname/settings.py is the right way to go, as some consider the .app-structure deprecated. If your app runs on a user account with a $HOME-directory, freedesktop recommends using the BaseDirectory (which would be something like ~/.config/appname) to store configuration files. See https://github.com/mbr/repl/blob/master/repl#L37 for an example.
  3. Maybe this should be a subclass and no alteration of the default behavior - although having too many subclasses defeatst the purpose of having a default in the first place.
mbr commented 10 years ago

One thing that just popped into my mind is the possibility of using os.pathsep to allow specifying more than one configuration filename (similar to $PATH).

Fiedzia commented 10 years ago
  1. It is significant change, but I think current code is to limited for me, and generally for flask users.
  2. Good point, mentioning ~/.config/app/settings.py is more appropriate.
  3. I see two ways to do it: a) have a explicitly defined subclass end-user must import and use instead of Appconfig - ultimately flexible, but verbose b) have an argument in Appconfig.init that would define exact class used for loading settings, either as a value from list (ie. model='unix') or c) classpath (model='flask.ext.appconfig...'). where model would be resolved to independent class or mixin.

I think I am a fan of option b). That way we could simply add parameter defining exact implementation, keep current as a default and keep it it all easy to use, without polluting user app namespace with internal details of appconfig.