Allow programmatic execution without importing aspen.__main__

[jaraco]

Logging should be implicitly configured or available to be explicitly configured, per this comment.

[pjz]

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

Logging input is (or should be) done with the usual

log = logging.getLogger(__name__)
log.debug(...)

in each module. The output should be configured by whatever app is using the aspen module. In the python -m aspen case, that's __main__ which is why that's configured there. In other cases (where aspen is used via WSGI, for instance), that set of logging configuration should be left to the calling app.

[jaraco]

But what if what I want to do is invoke aspen, just as python -m aspen does, except I need to perform some actions first. This is exactly the need in mongs. The referenced commit, by taking logging configuration out of the server initialization, will cause Mongs not to log anything (because logging hasn't been configured). There should be a way for Mongs to say, "Aspen, please configure logging output as you normally would".

[jaraco]

And without accepting this pull request, Mongs cannot do that except to import aspen.__main__, which is awkward, at best.

[pjz]

...or to just copy the code from aspen.__main__, which is what it's mostly there for: to serve as an example. In your scenario, I would actually just copy aspen/__main__.py into myapp.py and start hacking.

[jaraco]

So are you suggesting that the changelog for this next release will read something like:

Aspen no longer configures logging output during server setup. Instead, if your app requires configuration of logging, it should do that configuration itself. If you wish for the configuration to be the same as what Aspen normally outputs, your app should copy the 20 lines or so from aspen.__main__ into the startup routine for your app.

It strikes me as awkward that we would ask an app to copy code from aspen, especially when it's more than one or two lines, when it's trivially easy to expose that functionality to avoid the duplication (and unintended divergence).

Don't get me wrong. Using the logging framework is an excellent improvement. And giving the applications the ability to customize how output is managed is fantastic.

Would you accept a pull request that adds a comment directing users to copy that code into their projects?

[chadwhitacre]

/me picks up the convo in #541 ...

[chadwhitacre]

This is exactly the need in mongs.

permalink

[chadwhitacre]

Dialing back out here since we have an alternative PR in #545 ...

[chadwhitacre]

@jaraco Let's discuss this in terms of the roadmap for Aspen (#357). The tl;dr is that we're giving up on being a full-featured web framework, in light of the ascendency of Django and Flask (#526). Instead, we're going to provide dispatch and simplates as a plugin for Django and Flask, utilizing the request and response objects, etc., from those frameworks. We plan to ship a very basic framework using environ and start_response instead of Request and Response objects.

The implication for Mongs is that we'll need to decide what framework combo we want to use in the future: chadwhitacre/mongs#29.

especially when it's more than one or two lines

The implication for this ticket is that we should be trying to get __main__.py down to one or two lines. Skimming #527, I'm not sure we even log anything anymore on startup, which means we can cut out the logging config entirely, for example.

[jaraco]

Fine by me. I withdraw the PR.

[chadwhitacre]

!m @jaraco