Derzeit erwartet jinja2 entweder _pathdefinierte oder get_filenames: https://github.com/pallets/jinja/blob/master/src/jinja2/loaders.py#L262 -L281
Der pytest Assertion Rewriter definiert weder (siehe https://github.com/pytest-dev/pytest/blob/master/src/_pytest/assertion/rewrite.py#L48) und als solches Ausführen einer Testsuite auf einem Quellcode das hat folgendes global:
from jinja2 import PackageLoader
LOADER = PackageLoader(__name__, "templates")
wird scheitern mit:
raise ValueError(
E ValueError: The 'xxx' package was not installed in a way that PackageLoader understands.
Ich bin mir nicht sicher, ob jinja2 hier mehr Möglichkeiten unterstützen muss, um das Template-Rooot zu erhalten, oder dem pytest-Loader fehlen einige Methoden.
Dies scheint mit #1148 zu tun zu haben. Wir haben pkg_resources
und verwenden jetzt pkgutil.get_loader()
und loader.get_filename()
. Wenn der Loader von Pytest get_filename
bereitstellt, sollte es funktionieren.
Hier erkennen wir das Paket, es gibt auch einige Problemumgehungen im umgebenden Code, um ZIP- und Namespace-Importe zu unterstützen: https://github.com/pallets/jinja/blob/45a76a3794a91e6d7077ced88c814a96cc87d5c2/src/jinja2/loaders.py#L262 -L267
Der Loader von Pytest bietet keinen get_filename, wie ich im ersten Beitrag erwähnt habe. Sind Sie sicher, dass es für jeden Lader muss?
jinja2 macht Annahmen über Lader, die nicht Teil von PEP 451 sind – es sollte wahrscheinlich das .origin
Attribut der Modulspezifikation in pep451+-Welten verwenden
Wir brauchen eine Möglichkeit, den Pfad zu Dateien innerhalb eines Pakets abzurufen, um sie zu laden. Dies schien der Weg zu sein, dies mit den von Python bereitgestellten APIs zu tun, aber zugegebenermaßen war die Dokumentation darüber, wie man alles mit diesen APIs macht, für mich ziemlich undurchdringlich.
Wenn jemand einen besseren Vorschlag hat, der mit verschiedenen Loadern besser funktioniert und gleichzeitig Verzeichnisse, Zips und Namespaces unterstützt, würde ich mich über Hilfe freuen.
cc @jaraco
Wenn Sie eine Ressource laden möchten, sollten Sie nicht https://docs.python.org/3/library/importlib.html#module -importlib.resources verwenden; Sie müssen nicht die Quelle der Datei kennen, nur was sie enthält, nicht wahr?
resources
erfordert, dass alle "Ressourcen"-Verzeichnisse __init__.py
Dateien haben, was noch mehr mit der Arbeitsweise von Jinja kompatibel wäre. Siehe https://gitlab.com/python-devs/importlib_resources/issues/58#note_232533726 für mein Feedback dazu.
Dies könnte ein hilfreicher Ausgangspunkt sein, ich werde sehen, ob ich etwas Code in jinja2 einfügen kann: https://github.com/asottile/aspy.refactor_imports/blob/519ee18ea75e0045b9b53644c627c6817b2a0748/aspy/refactor_imports/classify.py#L76 -L91
Scheint eine Okklusion des ursprünglichen Designs für imporltib.resources
; die Übernahme in seiner aktuellen Form führt jedoch zu einer Regression der Funktionen für jinja2; nämlich, dass pytest plötzlich nicht mehr unterstützt wird; Also ja, wahrscheinlich sollte
Es sieht so aus, als ob importlib_resources
vielleicht ein Update erhalten hat, das Unterverzeichnisse zulässt? https://importlib-resources.readthedocs.io/en/latest/changelog%20 (links).html#v1-1-0 Könnte auch gut sein.
Egal, das Problem ist immer noch gültig.
In #1182 wieder pkg_resources für 2.11.2 verwendet, wird #1169 für 3.0 verwendet.
Können wir damit bitte eine Freigabe haben?
Warten auf einen anderen PR.
Kannst du es verlinken? 😄
Ich vermute, es ist #1183 angesichts des Meilensteins
Gerade veröffentlichte 2.11.2, die die Änderung rückgängig macht. 3.0 wird das neue Verhalten mit dem Fix haben.