Cela semble lié à #1148. Nous avons abandonné pkg_resources et utilisons maintenant pkgutil.get_loader() et loader.get_filename() . Si le chargeur de Pytest fournit get_filename cela devrait fonctionner.

Voici où nous détectons le package, il existe également des solutions de contournement dans le code environnant pour prendre en charge les importations de zip et d'espace de noms : https://github.com/pallets/jinja/blob/45a76a3794a91e6d7077ced88c814a96cc87d5c2/src/jinja2/loaders.py#L262 -L267

Le chargeur de Pytest ne fournit get_filename comme je l'ai souligné dans le premier message. Êtes-vous sûr que cela doit être le cas pour n'importe quel chargeur ?

jinja2 fait des hypothèses sur les chargeurs qui ne font pas partie du PEP 451 - il devrait probablement utiliser l'attribut .origin de la spécification du module dans les mondes pep451+

Nous avons besoin d'un moyen d'obtenir le chemin d'accès aux fichiers dans un package afin de les charger. Cela semblait être le moyen de le faire avec les API fournies par Python, mais il est vrai que la documentation sur la façon de faire quoi que ce soit avec ces API était à peu près impénétrable pour moi.

Si quelqu'un a une meilleure suggestion qui fonctionne mieux avec différents chargeurs tout en prenant en charge les répertoires, les zips et les espaces de noms, j'apprécierais son aide.

cc @jaraco

Si vous souhaitez charger des ressources, ne devriez-vous pas utiliser https://docs.python.org/3/library/importlib.html#module -importlib.resources ; vous n'avez pas besoin de connaître la source du fichier, juste ce qu'il contient, non ?

resources nécessite que tous les répertoires de "ressources" contiennent des fichiers __init__.py , ce qui serait encore plus incompatible avec le fonctionnement de Jinja. Voir https://gitlab.com/python-devs/importlib_resources/issues/58#note_232533726 pour mes commentaires à ce sujet.

cela pourrait être un point de départ utile, je vais voir si je peux mettre du code dans jinja2 : https://github.com/asottile/aspy.refactor_imports/blob/519ee18ea75e0045b9b53644c627c6817b2a0748/aspy/refactor_imports/classify.py#L76 -L76

On dirait que cela pourrait être une occlusion de la conception initiale pour imporltib.resources ; l'adopter dans sa forme actuelle entraîne une régression des fonctionnalités de jinja2 ; à savoir que tout à coup ne supporte plus pytest; alors oui, le code lié @asottile devrait probablement être ajouté pour combler le vide tandis que l'amont ajoute le support.

On dirait que importlib_resources être une mise à jour qui autorise les sous-répertoires ? https://importlib-resources.readthedocs.io/en/latest/changelog%20 (links).html#v1-1-0 Il serait peut-être bon de vérifier également.

1169 est une tentative de correctif, j'ai probablement encore besoin du journal des modifications, etc. mais vous pouvez probablement l'essayer et voir s'il résout votre problème @gaborbernat

Qu'à cela ne tienne, le problème est toujours d'actualité.

Revenu en #1182 à l'utilisation de pkg_resources pour 2.11.2, utilisera #1169 pour 3.0.

Pouvons-nous avoir une version avec cela s'il vous plaît?

En attente d'un autre PR.

Pouvez-vous le lier? ??

Je soupçonne que c'est #1183 étant donné le jalon

Vient de publier 2.11.2 qui annule le changement. 3.0 aura le nouveau comportement avec le correctif.