Opened 13 years ago

Last modified 9 years ago

#68 closed defect (FIXED)

Server config file

Reported by: Bernhard Keller Owned by: Christopher Allan Webber
Priority: minor Milestone: 0.0.3
Component: programming Keywords:
Cc: Parent Tickets:


add a config file mediagoblin.globals to handle variables like
keeps mediagoblin.ini cleaner and allows for server independent

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

Change History (11)

comment:1 by Bernhard Keller, 13 years ago

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

first version

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

comment:2 by Christopher Allan Webber, 13 years ago

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
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\_config and the whole config file in\_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:
` <>`_

comment:3 by Christopher Allan Webber, 13 years ago

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


    <ianbicking> paroneayea: hi
    <paroneayea> ianbicking: yo.  So we're using paste deploy for
        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
    <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 :)

comment:4 by Christopher Allan Webber, 13 years ago

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

-  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:


    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
    blah = foo

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

comment:5 by Christopher Allan Webber, 13 years ago


-  ` <>`_
-  ` <>`_
-  ` <>`_

comment:6 by Christopher Allan Webber, 13 years ago

Milestone: 0.0.3
Owner: set to Christopher Webber
Assigning to 0.0.3 and myself.

comment:7 by Christopher Allan Webber, 13 years ago

Component: Programming

comment:7 by Christopher Allan Webber, 13 years ago

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.

comment:8 by Christopher Allan Webber, 13 years ago

Status: NewClosed
-  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
-  We now have validation and type conversion; see
   mediagoblin/ 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!

comment:9 by Christopher Allan Webber, 13 years ago

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

comment:10 by Will Kahn-Greene, 12 years ago

The original url for this bug was .
#98: precedes

Note: See TracTickets for help on using tickets.