Pyramid-jinja2

Latest version: v2.10.1

Safety actively analyzes 685838 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 4 of 7

2.0.2

==================

- 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]

2.0.1

==================

- 86: Fix a regression caused by the new support for extending a template
relative to itself. Using ``{% extends "some_asset:spec.jinja2" %}`` was
no longer working and is now fixed. [mmerickel]

2.0

================

- Claim Python 3.4 support
[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]

Backward Incompatible Changes
-----------------------------

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

1.10

=================

- 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]

- prevent error when using `python setup.py bdist_wheel`
[msabramo]

1.9

================

- fix indentation level for Jinja2ProjectTemplate in scaffolds/__init__.py
[Bruno Binet]

- Remove unnecessary dependency on ``pyramid.interfaces.ITemplateRenderer``
which was deprecated in Pyramid 1.5.
[mmerickel]

- 68: Added `model_path_filter`, `route_path_filter` and `static_path_filter` filters
[Remco]

- 74: Fixed issue with route being converted as_const by jinja2 engine when using btyecode cache
[Remco]

1.8

================

- 70: Do not pin for py3.2 compatibility unless running under py3.2
[dairiki]

Page 4 of 7

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.