Atualmente, jinja2 espera _path defined ou get_filenames: https://github.com/pallets/jinja/blob/master/src/jinja2/loaders.py#L262 -L281
O reescritor de asserção pytest não define nenhum deles (consulte https://github.com/pytest-dev/pytest/blob/master/src/_pytest/assertion/rewrite.py#L48) e, como tal, executando um conjunto de testes em um código-fonte que tem o seguinte global:
from jinja2 import PackageLoader
LOADER = PackageLoader(__name__, "templates")
irá falhar com:
raise ValueError(
E ValueError: The 'xxx' package was not installed in a way that PackageLoader understands.
Não tenho certeza se aqui o jinja2 precisa oferecer suporte a mais maneiras de obter o rooot do modelo ou o carregador de pytest está faltando alguns métodos.
Isso parece relacionado a # 1148. Perdemos pkg_resources
e agora estamos usando pkgutil.get_loader()
e loader.get_filename()
. Se o carregador de Pytest fornecer get_filename
ele deve funcionar.
Aqui é onde detectamos o pacote. Também há algumas soluções alternativas no código ao redor para oferecer suporte a importações de zip e namespace: https://github.com/pallets/jinja/blob/45a76a3794a91e6d7077ced88c814a96cc87d5c2/src/jinja2/loaders.py#L262 -L267
O carregador do Pytest não fornece get_filename como indiquei no primeiro post. Tem certeza de que é necessário para qualquer carregador?
jinja2 está fazendo suposições sobre carregadores que não fazem parte do PEP 451 - ele provavelmente deve estar usando o atributo .origin
da especificação do módulo nos mundos pep451 +
Precisamos encontrar uma maneira de obter o caminho dos arquivos dentro de um pacote para carregá-los. Essa parecia ser a maneira de fazer isso com as APIs fornecidas pelo Python, mas admito que a documentação sobre como fazer qualquer coisa com essas APIs era praticamente impenetrável para mim.
Se alguém tiver uma sugestão melhor que funcione melhor com diferentes carregadores e ainda suporte diretórios, zips e namespaces, gostaria de receber a ajuda.
cc @jaraco
Se você deseja carregar algum recurso, não deveria estar usando https://docs.python.org/3/library/importlib.html#module -importlib.resources; não há necessidade de você saber a origem do arquivo, apenas o que ele contém, não é?
resources
requer que todos os diretórios de "recursos" tenham __init__.py
arquivos, o que seria ainda mais incompatível com o funcionamento do Jinja. Veja https://gitlab.com/python-devs/importlib_resources/issues/58#note_232533726 para meu feedback sobre isso.
este pode ser um ponto de partida útil, verei se consigo shimmy algum código em jinja2: https://github.com/asottile/aspy.refactor_imports/blob/519ee18ea75e0045b9b53644c627c6817b2a0748/aspy/refactor_imports/classify.py#L76 -L91
Parece que isso pode ser uma oclusão do design inicial de imporltib.resources
; adotá-lo em sua forma atual, embora cause regressão de recursos para jinja2; a saber, que de repente não suporta mais pytest; então sim, provavelmente o código vinculado @asottile deve ser adicionado para preencher a lacuna enquanto o upstream adiciona suporte.
Parece que importlib_resources
tem uma atualização que permite subdiretórios? https://importlib-resources.readthedocs.io/en/latest/changelog%20 (links) .html # v1-1-0 Pode ser bom verificar também.
Não se preocupe, o problema ainda é válido.
Revertido em # 1182 de volta ao uso de pkg_resources para 2.11.2, usará # 1169 para 3.0.
Podemos ter um lançamento com isso, por favor?
Esperando por outro PR.
Você pode vinculá-lo? 😄
Eu suspeito que seja # 1183 dado o marco
Acabou de lançar 2.11.2 que reverte a alteração. 3.0 terá o novo comportamento com a correção.