<p>jinja2 unterstützt den pytest-Loader nicht mehr</p>

Erstellt am 10. März 2020  ·  18Kommentare  ·  Quelle: pallets/jinja

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.

Alle 18 Kommentare

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.

1169 ist ein Versuch einer Fehlerbehebung, ich brauche wahrscheinlich noch Changelog usw., aber Sie können es wahrscheinlich ausprobieren und sehen, ob es Ihr Problem behebt @gaborbernat

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.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen