Configure logging initialization such that it can be readily initiali…

[jaraco]

…zed by a programmatic execution of aspen. Fixes #540.

Feel free to reject and develop an alternative, accept and tweak, or accept as-is.

[chadwhitacre]

Picking up from #540 ...

Okay, upon looking at this again, the current code is correct because: init_logging initializes handlers and formats and such, which a module should NOT do. This is why it's done in __main__.

@pjz The way I read this PR, init_logging initializes handlers, yes, and it's defined in __init__ ... but it's not called except during python -m aspen via __main__ (notice the functools.partial). No?

[chadwhitacre]

In other words, I think @pjz's concerns are misplaced, and I'm 👍 here.

Am I missing something, @pjz?

[jaraco]

That's the intention - expose the functionality so another caller might be able to re-use it, but still call it by default only in __main__.

[pjz]

Looking at the __main__ code now, I think that serve() should NOT have been refactored into __init__.py for similar reasons as I think init_logging() shouldn't be: The goal of python -m aspen is to serve as 1: a test/dev toy server and also 2: example code. Literally nothing else ever in the aspen module will call or use serve() and init_logging(). Production deploys shouldn't use them either - they should use uwsgi or the like to call a minimal wrapper around the WSGI entry point. I much prefer to not add an extra support/documentation burden to the module by instead encouraging people to copy the __main__ as a starting point.

[pjz]

I'd prefer the solution embodied by #545.

[chadwhitacre]

Closing per #540 (comment).