Improve the template-relative searchpath logic to search more possibilities
in the include-chain built up from templates including or extending
other templates. The logic for when the chain was longer than just one
template including another template was broken.

Require pyramid_jinja2 to be included even when using
pyramid_jinja2.renderer_factory. It is now a thin wrapper around the
default renderer and can be used to share the same settings with another
file extension. [mmerickel]

pyramid_jinja2must be included into the Configurator in order
to use pyramid_jinja2.renderer_factory otherwise you may see the
exception:

ValueError: As of pyramid_jinja2 2.3, the use of the
"pyramid_jinja2.renderer_factory" requires that pyramid_jinja2 be
configured via config.include("pyramid_jinja2") or the equivalent
"pyramid.includes" setting.

#88: Formalize template loading order and allow all lookups to fallback to
the search path. A template is now always searched for relative to its
parent template. If not found, the lookup will fallback to the search path.
[mmerickel]

Add prepend option to config.add_jinja2_search_path to allow
prepending of paths to the beginning of the search path if a path should
override previously defined paths. [mmerickel]

The 2.0 series started adding the package that invoked
config.add_jinja2_renderer to the template search path. This is
being removed in favor of explicit search paths and will hopefully not
affect many people as it has only been available for a couple weeks. The
only automatic search path left is the one added by the default .jinja2
renderer created when including pyramid_jinja2. [mmerickel]

Adjust the config.include('pyramid_jinja2') to add any packages from
jinja2.directoriesbefore the default search path at the base of
the app. Previously there was no way to override that search path.
[mmerickel]

The path of the child template is always considered when inheriting from
a base template. Therefore when doing render('templates/foo.jinja2')
and foo.jinja2 has an {%extends'base.jinja2'%}, the template
will be searched for as 'templates/base.jinja2' on the search path.
Previously the path of the child template was ignored when doing the
lookup for the base, causing some very subtle and unrecoverable lookup
errors when the child template was found relative to the caller instead
of being found on the search path. [mmerickel]

This release restores the default search path behaviors from the 1.x series
that were inadvertently removed in the 2.x. The project’s root package is
added to the search path by default. [mmerickel]

#75: Fix the missing piece of relative template loading by allowing a
template to inherit from a template relative to itself, instead of
forcing the parent to be on the search path.
[mmerickel]

#73: Added a new config.add_jinja2_renderer API that can create and
override multiple Jinja2 renderers, each loaded using potentially different
settings and extensions.

The other APIs are now keyed on the renderer extension, as each extension
may have different settings. Thus config.add_jinja2_search_path,
config.add_jinja2_extension, and config.get_jinja2_environment
accept a name argument, which defaults to .jinja2.

This deprecates the old pyramid_jinja2.renderer_factory mechanism
for adding renderers with alternate extensions.

Configuration of the renderers has been updated to follow Pyramid’s
standard mechanisms for conflict detection. This means that if two modules
both try to add a renderer for the .jinja2 extension, they may raise a
conflict or the modifications made by the invocation closest to the
Configurator in the call-stack will win. This behavior can be affected
by calling config.commit at appropriate times to force a configuration
to take effect immediately. As such, configuration is deferred until
commit-time, meaning that it is now possible
config.get_jinja2_environment will return None because the changes
have not yet been committed.
[mmerickel]

The creation and configuration of the Jinja2 Environment is now deferred
until commit-type in the Pyramid Configurator. This means that
config.get_jinja2_environment may return None. To resolve this,
invoke config.commit() before attempting to get the environment.

#77: Change semantics of jinja2.bytecode_caching setting. The new
default is false (no bytecode caching) – bytecode_caching must
explicitly be set to true to enable a filesystem bytecode cache.
In addition, an atexit callback to clean the cache is no longer
registered (as this seemed to defeat most of the purpose of having
a bytecode cache.) Finally, a more complex bytecode cache may be
configured by setting jinja2.bytecode_caching directly to a
jinja2.BytecodeCache instance. (This can not be done in a
paste .ini file, it must be done programatically.)
[dairiki]

Changes to normalize with default templates shipping with Pyramid core:
remove calls to config.begin() and config.end() from
__init__.main, entry point name changed to main, entry
__init__.py function name changed to main, depend on WebError, use
paster_plugins argument to setup function in setup.py, depend on
Pyramid 1.0a6+ (use config rather than configurator).

First release. Not backwards compatible with repoze.bfg.jinja2: we
use a filesystem loader (the directories to load from come from the
jinja2.directories setting). No attention is paid to the current
package when resolving a renderer= line.