<p>jinja2 больше не поддерживает загрузчик pytest</p>

Созданный на 10 мар. 2020  ·  18Комментарии  ·  Источник: pallets/jinja

В настоящее время jinja2 ожидает либо _path defined, либо get_filenames: https://github.com/pallets/jinja/blob/master/src/jinja2/loaders.py#L262 -L281

Переписчик утверждений pytest не определяет ни того, ни другого (см. Https://github.com/pytest-dev/pytest/blob/master/src/_pytest/assertion/rewrite.py#L48), и как таковой запуск набора тестов в исходном коде который имеет следующие глобальные:

from jinja2 import PackageLoader
LOADER = PackageLoader(__name__, "templates")

потерпит неудачу с:

    raise ValueError(
E   ValueError: The 'xxx' package was not installed in a way that PackageLoader understands.

Не уверен, что здесь jinja2 должен поддерживать больше способов получить рут шаблона, или в загрузчике pytest отсутствуют некоторые методы.

Все 18 Комментарий

Похоже, это связано с # 1148. Мы отказались от pkg_resources и теперь используем pkgutil.get_loader() и loader.get_filename() . Если загрузчик Pytest предоставляет get_filename он должен работать.

Здесь мы обнаруживаем пакет, в окружающем коде также есть некоторые обходные пути для поддержки импорта zip-файлов и пространств имен: https://github.com/pallets/jinja/blob/45a76a3794a91e6d7077ced88c814a96cc87d5c2/src/jinja2/loaders.py#L262 -L22 -L2

Загрузчик Pytest не предоставляет get_filename, как я указал в первом посте. Вы уверены, что это обязательно для любого загрузчика?

jinja2 делает предположения о загрузчиках, которые не являются частью PEP 451 - вероятно, он должен использовать атрибут .origin спецификации модуля в мирах pep451 +

Нам нужен способ получить путь к файлам в пакете, чтобы загрузить их. Похоже, это был способ сделать это с API, предоставляемыми Python, но, надо признать, документация о том, как что-либо делать с этими API, была для меня в значительной степени непонятной.

Если у кого-то есть лучшее предложение, которое лучше работает с разными загрузчиками, но при этом поддерживает каталоги, zip-файлы и пространства имен, я был бы признателен за помощь.

cc @jaraco

Если вы хотите загрузить какой-либо ресурс, не следует ли вам использовать https://docs.python.org/3/library/importlib.html#module -importlib.resources; вам не нужно знать источник файла, просто то, что он содержит, не так ли?

resources требует, чтобы во всех "ресурсных" каталогах были файлы __init__.py , что было бы еще более несовместимо с тем, как работает Jinja. См. Мой отзыв об этом на https://gitlab.com/python-devs/importlib_resources/issues/58#note_232533726 .

это может быть полезной отправной точкой, я посмотрю, смогу ли я вставить какой-нибудь код в jinja2: https://github.com/asottile/aspy.refactor_imports/blob/519ee18ea75e0045b9b53644c627c6817b2a0748/aspy/refactor_imports/classify.py#L

Похоже, это может быть перекрытие первоначального дизайна для imporltib.resources ; принятие его в его нынешней форме вызывает регресс функций для jinja2; а именно то, что внезапно больше не поддерживает pytest; так что да, вероятно, следует добавить связанный код поток добавляет поддержку.

Похоже, что, возможно, importlib_resources получил обновление, разрешающее подкаталоги? https://importlib-resources.readthedocs.io/en/latest/changelog%20 (links) .html # v1-1-0 Также неплохо было бы проверить.

1169 - это попытка исправить, мне, вероятно, все еще нужен журнал изменений и т. Д., Но вы, вероятно, можете попробовать его и посмотреть, решит ли он вашу проблему @gaborbernat

Ничего, проблема все еще актуальна.

Возвращено в # 1182 обратно к использованию pkg_resources для 2.11.2, будет использовать # 1169 для 3.0.

Можем ли мы сделать релиз с этим, пожалуйста?

Жду еще одного пиара.

Вы можете связать это? 😄

Я подозреваю, что это номер 1183, учитывая веху

Только что выпущенная версия 2.11.2 отменяет изменения. 3.0 будет иметь новое поведение с исправлением.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги