Around last December, I got annoyed with the way PasteDeploy combines
the INI file parsing with the WSGI object loading. INI files are awfully
clumsy and there are many alternatives that offer features such as lists
and nested dicts, but as long as WSGI object loading was done through
PasteDeploy, Pyramid could not easily take advantage of these config
formats.
(Of course, I could write my own bin script to launch my Pyramid app
using my WSGI server of choice, loading config from a JSON file, but
this doesn't let me take advantage of the Pyramid tools such as pshell
or pviews.)
This kind of flexible configuration is particularly important as Docker
and similar tools become more popular for deploying apps. My Postgres
database may change IP from deployment to deployment, but the correct IP
is always available in environment variables. Of course, I can pull
values from environment variables in my Python code, but I have to
special case that everywhere that config settings might get loaded.
Montague provides a solution to this through "montague_mako", which
renders a Mako template with environment variables into a config file of
any kind.
Montague also provides full PasteDeploy backwards compatibility (through
an optional package). I'll be honest, figuring out how to do this sanely
is what took the bulk of the time.
I wrote a blog post about Montague here, which includes a demo loading a
WSGI app, middleware, and server from a TOML file:
https://metaclassical.com/announcing-montague-the-new-way-to-configure-python-applications/
It is also being used by at least one person other than me.
The project is still in early stages and the docs are kind of lacking.
But I think the code speaks for itself. I am using Montague while
developing my next Pyramid app and I am forking pserve/pshell/etc to
work with it.
I've encountered one particular difficulty with pshell and other Pyramid
scripts: Montague allows a config file to have more than one logging
config, which means I've combined development.ini and production.ini
into a single config.toml. pserve lets you specify which app and server
to load (while pshell does not, except with the PasteDeploy #app
syntax), but none of the scripts have a --logging-config argument.
It seems to me that it would be good for the p*scripts to standardize on
one particular way to specify the app, server, and logging config to
load from the config files. Would anyone be opposed to a pull request
making these changes?
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.
