Separate out and geniericify utility for parsing config from mediagoblin/celery_setup/__init__.py

[Christopher Allan Webber]

It would be great if we could have something like:

::

    >>> from mediagoblin.util import parse_app_config
    >>> parse_app_config(path_to_config_file, app_section='app:mediagoblin')
    (app_config, global_config)

where the former is the app config (a dictionary of all values you
see in [app:mediagoblin] in mediagoblin.ini) and the latter is the
global config (a dictionary of dictionaries for all sections).

This tool kind of already exists in
mediagoblin/celery\_setup/**init**.py, you can see a section like:

::

        parser = NicerConfigParser(mgoblin_conf_file)
        parser.read(mgoblin_conf_file)
        parser._defaults.setdefault(
            'here', os.path.dirname(os.path.abspath(mgoblin_conf_file)))
        parser._defaults.setdefault(
            '__file__', os.path.abspath(mgoblin_conf_file))
    
        mgoblin_section = dict(parser.items(mgoblin_section))
        mgoblin_conf = dict(
            [(section_name, dict(parser.items(section_name)))
             for section_name in parser.sections()])

This should be:


-  separated out into an independent utility
-  given tests in mediagoblin/tests/test\_util.py
-  able to take the specific section as the app\_section keyword
   argument (defaults to 'app:mediagoblin')
-  bonus feature? If 'app:mediagoblin' is not found maybe we could
   find the section by iterating through until we find the one that
   has 'use': 'egg:mediagoblin#app'

[Matt Johnson]

Question - For the bonus feature part:

Since it is not looking for specifically 'app:mediagoblin' and
instead is using a variable, do we want the bonus feature to find
using that same pattern?

ex.

if app:mediagoblin not found, find egg:mediagoblin#app
if app:foo not found, find egg:foo#app
if foo:bar not found, find egg:bar#foo

[Christopher Allan Webber]

I wonder if the bonus feature is too magical and a bad idea... it's
probably best to implement it outside of the actual utility if
done.

Scrap the bonus! It's probably too magical, I think.

[Matt Johnson]

Cool. Then, I basically have this written in it's own module but
I'm not sure how to set up tests because I'm terribly new to
Python. Can someone point me to a good resource on creating tests?

[Christopher Allan Webber]

Great! So there's some documentation on tests on:


-  `http://somethingaboutorange.com/mrl/projects/nose/1.0.0/ <http://somethingaboutorange.com/mrl/projects/nose/1.0.0/>`_
-  `http://docs.python.org/library/unittest.html <http://docs.python.org/library/unittest.html>`_

We use nose which has some wrappers around unittest... for one
thing, it makes things nicer because it makes writing tests super
easy.

You'll want to put the utility in mediagoblin/tests/test\_util.py

But if you want a really easy example of what tests look like, I
suggest looking at test\_globals.py's test\_setup\_globals function
which is pretty straightforward:

::

    def test_setup_globals():
        mg_globals.setup_globals(
            db_connection='my favorite db_connection!',
            database='my favorite database!',
            public_store='my favorite public_store!',
            queue_store='my favorite queue_store!')
    
        assert mg_globals.db_connection == 'my favorite db_connection!'
        assert mg_globals.database == 'my favorite database!'
        assert mg_globals.public_store == 'my favorite public_store!'
        assert mg_globals.queue_store == 'my favorite queue_store!'

See, all you need to do is put a
test*foo method in one of the test*\* modules in mediagoblin/tests/
and when you run ./bin/nosetests it should pick it up and see if it
works.

Just store a simple config file in the tests/ directory, use
pkg\_resources to pick it up like so:

::

    import pkg_resources
    config_filename = pkg_resources.resource_filename(
            u'mediagoblin.tests', u'fakeconfig.ini')

should pick up the filename (but not load it)

Then just run that file through your utility, do asserts to make
sure that everything's returned in the way that you expected. Next
time you run ./bin/nosetests it should pick up your test function
and make sure that everything **does** work.

Does that make sense?

[Christopher Allan Webber]

Hey Matt,

Mind tacking your current progress to the ticket, preferably by
using git format-patch? (but optionally pushing a git branch I can
access works also) This would be helpful even if you don't have
tests written yet.

[Christopher Allan Webber]

When this is done we should update
`http://bugs.foocorp.net/issues/344 <http://bugs.foocorp.net/issues/344>`_

[Matt Johnson]

Hi Chris,

Sorry for the delay. I've had some connectivity issues at home.
I'll get this posted ASAP.

Thanks,

Matt

[Christopher Allan Webber]

Okay great, looking forward to seeing it!

[Christopher Allan Webber]

This is done, almost. I changed my mind a bit and selecting a
section is not really done via the function itself because it's
easy enough to select it yourself via the key. Not everything is
switched over yet though, and tests aren't written. Getting close
though.

[Christopher Allan Webber]

This is actually resolved really with the new ConfigObj branch
being merged in.

[Elrond]

This wasn't targeted at 0.0.3, but will now be in that version, so
change it.
Makes looking at the bugs a nice way to see, what happened, for
release notes.
As Christopher Webber did most of the work, assigning to him. ;)

[Christopher Allan Webber]

Also this should be closed, not resolved!

[Will Kahn-Greene]

The original url for this bug was ​http://bugs.foocorp.net/issues/297 .