<p>jinja2 não suporta mais o carregador pytest</p>

Criado em 10 mar. 2020  ·  18Comentários  ·  Fonte: pallets/jinja

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.

Todos 18 comentários

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.

1169 é uma tentativa de consertar, provavelmente ainda preciso do changelog etc., mas você provavelmente pode experimentá-lo e ver se corrige o seu problema @gaborbernat

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.

Esta página foi útil?
0 / 5 - 0 avaliações