I'm not arguing that this is the best way, but as a data point, here's what
I do.
I use buildout to generate app.ini, as well as other config files,
including for uwsgi and supervisord, from templates (using
collective.recipe.template.) I have several top-level buildout config
files, all of
On Tuesday, November 10, 2015 at 11:58:22 AM UTC-5, Jeff Dairiki wrote:
>
> I'm not arguing that this is the best way, but as a data point, here's
> what I do.
>
I'm mad I didn't think of this! It's a great solution for me, because we
already have a `fabric` script do much of the same as
On Saturday, November 7, 2015 at 12:22:40 AM UTC-5, Mike Orr wrote:
>
> The ideal way would be to have a different INI file for different kinds of
> deployment
>
I used to believe that... but as projects progressed, ini files got larger
and more difficult to maintain. It's hard enough
On Sat, Nov 7, 2015 at 12:56 PM, Jonathan Vanasco wrote:
> Splitting this out into "production-admin.ini" and
> "production-non_admin.ini" files to declare a single variable would mean
> having another file to update whenever other ini settings change.
You can inherit
On Sat, Nov 7, 2015 at 12:56 PM, Jonathan Vanasco
wrote:
>
>
> On Saturday, November 7, 2015 at 12:22:40 AM UTC-5, Mike Orr wrote:
>>
>> The ideal way would be to have a different INI file for different kinds
>> of deployment
>>
>
> I used to believe that... but as
On Fri, Nov 6, 2015 at 1:39 PM, Jonathan Vanasco wrote:
> * pyramid is deployed via uwsgi , which is controlled by supervisord.
> * uwsgi is invoked using the `--ini-paste--logged` argument, which which
> points to the "production.ini"
>
> I was thinking that the easiest
I'm trying to squeeze some more performance out of a cluster and an easy
fix was segmenting out all the "admin" routes/views to be conditionally
enabled. (This saves enough MB per process that I can run a handful more
processes. yay.)
I'm trying to figure out a good way to re-enable the