Features: single lookup and debugtoolbar panel

[jvanasco]

These are proposed in one PR, because the panel was built/used for debugging this feature (and it's generally useful).

The current implementation detail for pyramid_mako is to create a unique template lookup for each extension, and register them into Pyramid. These template lookups are only used by Pyramid's render tools though -- not by Mako itself -- so any files "included" or "inherited" by a mako template will need to be built for the current lookup -- and not leverage already being compiled for a dedicated extension lookup.

For example: if home.mako inherits from layout.mak, the current version of pyramid_mako will compile layout.mak in the template lookup dedicated to ".mako" files whether or not it exists in the separate template lookup dedicated to ".mak" file extensions.

This proposed update allows for multiple extensions to be declared at once -- sharing a single template lookup for the group of extensions.

This appears to work in light usage and tests pass, but it could definitely use some insight and think-through by others for potential edge cases or issues.

[digitalresistor]

I understand why you put the two together, but I would like to see two separate PR's for them please, this makes review simpler, and allows us to discuss changes related to one single change at a time, rather than both.

[jvanasco]

The toolbar panel was included because it simply exposed the inner-workings of the mako engine, and was entirely dependent on this feature. It's been removed from the PR, but is not possible to submit in it's own PR at this time.

[digitalresistor]

Once this work is merged, you'll be able to create a PR for the toolbar!

[mmerickel]

Did you consider something like config.add_mako_renderer_alias(renderer='.mako', alias='.mak')? This would allow people to add their own aliases without overwriting the entire pre-existing configuration.

[jvanasco]

Did you consider something like config.add_mako_renderer_alias(renderer='.mako', alias='.mak')? This would allow people to add their own aliases without overwriting the entire pre-existing configuration.

That idea didn't occur to me. I just noticed the existing implementation created two isolated environments for .mako and .mak by default, and wanted to unify them without changing the existing API.

I considered creating a single global lookup/collection and re-using that across invocations, but I thought there could exist situations where that isn't desired -- so limiting the applicable extensions for a single factory/lookup to what was explicitly declared at the time would be preferred.

[mmerickel]

I would be fine with a solution that grouped the environments based on the settings prefix used. The only reason it doesn't do that already is because I didn't want to store the environments on the registry using that prefix because it was extra work at the time. Thus the first action would store the environment on the registry and the second one would find it and re-use it instead of creating a new one. I see very few problems with this as settings are intended to be global to an app, so if people are expecting the environments to be different then they should use different settings prefixes.