Server config file

[Bernhard Keller]

add a config file mediagoblin.globals to handle variables like
PAGINATION\_DEFAULT\_PER\_PAGE and
ATOM\_DEFAULT\_NR\_OF\_UPDATED\_ITEMS
keeps mediagoblin.ini cleaner and allows for server independent
settings

later users would be able to customise some of the parameters
values that differ from the default config, would be stored as user
dependent values in the database

[Bernhard Keller]

[https://gitorious.org/\ :sub:`hunabku/mediagoblin/hunabkus-mediagoblin/commits/feature\_global\_config](https://gitorious.org/`\ hunabku/mediagoblin/hunabkus-mediagoblin/commits/feature\_global\_config)

first version

all variables in mediagoblin.globals get imported into the globals
module
missing variables get set to default values and written into the
config file
config file is created if it doesnt exist

[Christopher Allan Webber]

Hm. I've been thinking about this kind of user configuration for a
while. I appreciate the approach you're taking here... I'm not 100%
sure it's what we should do, but for what you're doing it does look
good.
I've had some thoughts that we should have an admin system where
users are able to store their config stuff in the database for
things like pagination numbers, etc. But obviously we don't have
that yet, and we probably won't for a while. I'm thinking about
this, anyway. I may want to do something simpler where we just
store everything in the [app:mediagoblin] section in
mediagoblin.globals.app\_config and the whole config file in
mediagoblin.globals.global\_config. For now your solution **might**
be the right way but I still need to think about it. :)

But anyway, along this form: let me suggest that instead of trying
to do conversions between the different types yourself, use
ConfigObj which does all that stuff for you:
`http://www.voidspace.org.uk/python/configobj.html <http://www.voidspace.org.uk/python/configobj.html>`_

[Christopher Allan Webber]

As it turns out I just had a conversation with Ian Bicking in
#pythonpaste

::

    <ianbicking> paroneayea: hi
    <paroneayea> ianbicking: yo.  So we're using paste deploy for
                 http://mediagoblin.org/ and in a few parts of the program I have
                 to open up the config file and read other sections out of it
    <paroneayea> I think the documentation for this (maybe even the actual
                 interfaces) could be a lot better
    <paroneayea> so maybe I should write some documentation patches :)
    <paroneayea> I partly wonder also if I'm doing things the right way at all.  I
                 ended up both reading via paste.loadwsgi.appconfig and by faking
                 reading the whole config file
                 https://gitorious.org/mediagoblin/mediagoblin/blobs/master/mediagoblin/util.py#line354
    <paroneayea> not in the same place though :)
    <ianbicking> paroneayea: maybe in that case it makes sense not to use paste
                 deploy for the entire app configuration
    <ianbicking> e.g., fall back on a paste deploy config that looks like:
    <ianbicking> [app:main] use = egg:MediaGoblin \n config = %(here)s/media.ini
    <paroneayea> ianbicking: hm, okay :)
    <paroneayea> maybe we can just use ConfigObj then also.
    <paroneayea> ianbicking: thanks for the advice

... so I am warming up to this idea :)

[Christopher Allan Webber]

So I did some research into ConfigObj and it looks like it can
handle everything I hoped, dreamed for and far, far more.

So the config setup we have currently is a mess. I have a vision
for how to make it better, and I'm not sure if I'm going to do it
myself or if I should pass it off to someone else. But here's some
thoughts.


-  Yes, we should have a separate file for configuration... that
   seems much clearer to me now.
-  Looks like we can handle validation and even
   **type conversion!** from our config files via ConfigObj
-  We should make sure we support %(here)s stuff, see the
   interpolation section

Probably things will look like:

::

    [mediagoblin]
    something = foo
    something_else = 403094
    some_directory %(here)s/path/to/something
    
    # finally we can do *REAL* conversion of these values straight out of the config file!
    # Amazing.
    [celery] # maybe [mediagoblin.celery] ?
    something = something
    something_else = something
    
    [some_plugin]
    blah = foo

This could really simplify a heck of a lot of initialization code.

[Christopher Allan Webber]

Resources:


-  `http://www.voidspace.org.uk/python/configobj.html <http://www.voidspace.org.uk/python/configobj.html>`_
-  `http://www.voidspace.org.uk/python/validate.html <http://www.voidspace.org.uk/python/validate.html>`_
-  `http://www.voidspace.org.uk/python/articles/configobj.shtml#validation <http://www.voidspace.org.uk/python/articles/configobj.shtml#validation>`_

[Christopher Allan Webber]

Assigning to 0.0.3 and myself.

[Christopher Allan Webber]

The configobj loading stuff as well as validation, type conversion,
interpolation stuff is handled now, with unit tests! I'm pretty
happy about it.

But the application isn't using it. This ticket has grown a little
bit in scope... I'm going to take the opportunity while factoring
this into here to make instantiating the application a lot easier
and cleaner.

[Christopher Allan Webber]

-  There are now two config files, server.ini and mediagoblin.ini.
   
   -  server.ini is for the paste deploy config
   -  mediagoblin.ini is for the actual configuration of the
      mediagoblin application

-  This means that the command to launch the server has been
   updated From the python point of view:
-  Getting an application instance is as easy as initializing
   MediaGoblinApp(config\_file\_path)
-  We now have validation and type conversion; see
   mediagoblin/config.py and mediagoblin/config\_spec.ini
-  Celery's defaults and etc also handled by the config system.
-  The code for plenty of things is much, much cleaner now.

Anyway, done, closed, wooo!

[Christopher Allan Webber]

Also, special thanks for Bernard for proving that this was a good
idea. :)

[Will Kahn-Greene]

The original url for this bug was ​http://bugs.foocorp.net/issues/351 .
Relations:
#98: precedes