Re: [pylons-devel] PasteDeploy in the Pylons GitHub org?

[Jon Rosebaugh]

On 3/9/16 12:29 PM, Karl O. Pinc wrote:

On Wed, 9 Mar 2016 03:18:49 -0600
"Karl O. Pinc"  wrote:


On Tue, 8 Mar 2016 20:26:36 -0800
Mike Orr  wrote:


On Tue, Mar 8, 2016 at 4:22 PM, Michael Merickel
 wrote:



I think with the advent of montague by Joe Rosenbaugh as well as
12-factor app design I know, personally, that I'm ready to start
having a conversation about what to do in this space.



Still, it would be nice to have something cleaner than INI and
PasteDeploy in Pyramid's default, but I also don't know what would
be a good candidate for that.


Raw python literal expressions parsed with ast.literal_eval(),
read from a file.



Sounds fun, but my python-fu is not strong.  Here's
a horrible example:


Appended is a better proof-of-concept.
It extends the original by allowing tuple values.

I thought maybe montague would do this, but I don't see it.


Montague can definitely allow this -- it doesn't ship with support for 
any format except INI files, but it's got pluggable support for other 
formats.


You just need to pick a file extension for this particular file format, 
and make a package that provides an entry point for that file extension, 
and which implements a simple interface. Talk to me on IRC or by email 
and I'll walk you through this.


--
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 https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] wsgi server of choice?

[Jon Rosebaugh]

I generally set up with nginx (as ssl terminator, etc) reverse-proxying
to gunicorn. Waitress would work just as well as gunicorn for quite a
lot of deployments.

On Thu, Sep 24, 2015, at 12:25 PM, Chris Withers wrote:
> Hi All,
> 
> What's the recommended wsgi server for Pyramid apps nowadays? 
> 
> My go-to would normally be mod_wsgi, but I'm having a hard time getting
> my 
> head around using that with an environment set up with environment
> modules 
> .
> 
> That modules system is causing me plenty of other headaches (IDE 
> integration, etc), but it is what I have to work with, so interested in
> any 
> recommendations for a wsgi server that would work with that type of 
> environment...
> 
> cheers,
> 
> Chris
> 
> -- 
> 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.

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

Re: [pylons-devel] Announcing Montague: replace INI with YAML, JSON, etc

[Jon Rosebaugh]

On 7/2/15 6:35 PM, Mike Orr wrote:

I found an issue with TOML files. It says you can't have a dot in a
key name, but some consumers look for dotted keys
("pyramid.reload_templates", "debugtoolbar.enabled"). Can those
settings not be used without postprocessing the settings?


Dots are prohibited in bare keys, but all you have to do is wrap the key 
in quotes. e.g.:


[some_section]
simple_value = "foo"
"pyramid.dotted.value" = "bar"

is parsed into this Python dict:

{u'some_section': {u'simple_value': u'foo', u'pyramid.dotted.value': 
u'bar'}}


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

Re: [pylons-devel] Announcing Montague: replace INI with YAML, JSON, etc

[Jon Rosebaugh]

On 6/28/15 3:39 AM, Domen Kožar wrote:

ConfigParser does allow "file inheritance", but sadly PasteDeploy never
used the feature:

https://docs.python.org/2/library/configparser.html#ConfigParser.RawConfigParser.read


Logging configuration isn't actually done with PasteDeploy; 
logging.config provides a fileConfig function. I'm not surprised it 
doesn't work with inheritance, though.


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

[pylons-devel] Announcing Montague: replace INI with YAML, JSON, etc

[Jon Rosebaugh]

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.