is there a standardized way of detecting the environment (e.g. bootstrap)

37 views
Skip to first unread message

Jonathan Vanasco

unread,
Mar 13, 2019, 3:33:10 PM3/13/19
to pylons-discuss
there seems to be a few ways a pyramid app can be run

is there a way to detect if the current application was started via `pyramid.paster.bootstrap`? 

i'm trying to sketch out a (public) plugin that can log application startups and invocations.

Michael Merickel

unread,
Mar 13, 2019, 3:53:54 PM3/13/19
to Pylons
No bootstrap does not inject any custom settings or anything into the app.

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
To post to this group, send email to pylons-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/2329b3cc-55d8-4aca-a19d-2f3f4ff0ed5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jonathan Vanasco

unread,
Mar 20, 2019, 1:15:01 PM3/20/19
to pylons-discuss
Thanks for the quick reply, Michael.  I'll have to ponder a solution to this problem for a bit.

Michael Merickel

unread,
Mar 20, 2019, 2:22:12 PM3/20/19
to Pylons
The hackiest option possible is to just set a global variable somewhere when you use bootstrap. Otherwise you could use a custom setting.

Jonathan Vanasco

unread,
Mar 20, 2019, 5:12:18 PM3/20/19
to pylons-discuss


On Wednesday, March 20, 2019 at 2:22:12 PM UTC-4, Michael Merickel wrote:
The hackiest option possible is to just set a global variable somewhere when you use bootstrap. Otherwise you could use a custom setting.

Oh, I can think of hackier ways!

One thing I considered was overriding bootstrap and pshell with a custom package, which just sets a global variable and then provides the actual underlying tools.  I still have to go through all the ways of running a pyramid application.  I was originally leaning towards custom config files, but worry about correctly supporting the wide range of config options.

The use-case for the plugin i'm trying to build is centrally logging how/when multiple pyramid processes run to monitor health.  One project, for example, has three pyramid apps running and about a dozen cronjobs running bootstrap or prequest.  It's currently using ENV variables to control the logging, but it's very messy.  I'd like to standardize this into something that can cleanly run for all our projects and be released on PyPi.


Mike Orr

unread,
Mar 21, 2019, 12:57:36 PM3/21/19
to pylons-...@googlegroups.com
If the reason you want to know whether you're running under bootstrap
is to determine whether logging has been configured, I ran into that
with uwsgi, that it has an option to load a paste.deploy config file
and initialize logging from it, but it didn't initialize the logging,.
So I added a setting 'logging' with the path to the config file. In my
main function, if it's set, I call logging.config.fileConfig on it.

I don't remember whether I set the value to '%(__file__)s' or
'%(here)/myconfig.ini', because that was another issue I ran into.
paste.deploy sets it, and the pyramid.paster functions may set it, but
ConfigParser doesn't.

Jonathan Vanasco

unread,
Mar 21, 2019, 1:35:34 PM3/21/19
to pylons-discuss

On Thursday, March 21, 2019 at 12:57:36 PM UTC-4, Mike Orr wrote:

If the reason you want to know whether you're running under bootstrap
is to determine whether logging has been configured,

We log every startup/invocation of the app/scripts to a centralized database.

There's a table that lists every startup with a timestamp and the context - uwsgi/waitress workers, prequest, and bootstrap, along with a node identifier for the machine and some other data.  

It is one of the systems used for healthchecks, to ensure everything is running properly and help auditing during post-mortem incident analysis.  The raw logs often get cycled into oblivion or destroyed, so this helps us pinpoint where to dig in to data first by detecting when cronjobs stopped running or when applications spiraled into endless restarts.  Other tools ensure services are running or jobs have completed, this is just one useful component of monitoring.

Reply all
Reply to author
Forward
0 new messages