Jinja: Entscheiden Sie sich für eine einheitliche Benennung von entweder `Jinja` oder `Jinja2`

Das Stack Overflow-Tag ist "jinja2", "jinja" ist ein Synonym, das unsichtbar konvertiert wird. Trotz meiner Bemühungen um das Gegenteil. (Dies geschah vor etwa einem Jahr.)

Ich möchte wirklich die "2" aus dem Namen streichen. Beginnen Sie mit dem Hinzufügen von v2-Builds zur PyPI-Seite "jinja". Setzen Sie den Import von "jinja2" als veraltet ein und kehren Sie zum Namespace "jinja" zurück.

@ThiefMaster @mitsuhiko @untitaker habt ihr Meinungen?

Ich denke, das können wir tun, aber ich würde persönlich vorschlagen, die Version 3.0 daran auszurichten.

:+1: beim Warten auf 3.0.

Das Stack Overflow-Tag ist "jinja2", "jinja" ist ein Synonym, das unsichtbar konvertiert wird. Trotz meiner Bemühungen um das Gegenteil. (Dies geschah vor etwa einem Jahr.)

Vielleicht kann ich das beheben.

Edit: Ja, ich kann

Vorschau umbenennen
jinja2 wird aus 3486 Fragen entfernt
jinja wird zu 3486 Fragen hinzugefügt
5 Verpflichtungen gegenüber jinja2 Der Dokumentationsvorschlag wird in den jinja-Vorschlag verschoben
Ein Tag-Synonym-Mapping jinja2 → jinja wird erstellt.
(Diese Anzahl umfasst gelöschte Fragen und schließt überlappende Tags aus)

Wie sieht der Zeitplan für die Version 3.0 aus?

Je früher wir anfangen, Leute ein Heads - up , desto besser, so was ist eine deprecation Warnung jetzt über das Hinzufügen von jinja2 Importe und eine Warnung auf jinja Importe , dass wir bald v3 heraus zum drängen jinja Namensraum?

@davidism können Sie den RTD-Namespace nach jinja ? Gemäß meinem obigen Kommentar liegt es derzeit unter jinja2 , und IIRC, Sie haben die Bereinigung/Eigentumsmigration der RTD-Namespaces für andere Projekte vorangetrieben?

In gewisser Weise war die letzte große Veröffentlichung von Jinja2 eine massive Änderung der Engine. Nicht einmal sicher, ob wir noch mehr Sachen kaputt machen müssen :D

Das Speichern von Breaking Changes und Namenskonsolidierung für eine Jinja v3 klingt für mich großartig. Wir könnten genauso gut versuchen, die bahnbrechenden Veränderungen zu finden, die wir dafür planen können.

Ich möchte jeden an einen möglichen erinnern, der enthaltene Blocküberschreibungen erlaubt . Dieses Problem muss keine bahnbrechende Änderung bedeuten, aber wenn dies der Weg ist, den Sie alle gehen möchten, würde ich dieses Problem mit einem v3-Meilenstein neu erstellen / öffnen. Sorry für die Tangente. :) Vielleicht können wir ein weiteres Ticket erstellen, um zu diskutieren, was für Jinja v3 zu brechen / zu erreichen ist.

stupse @davidism - kannst du gemäß meinem obigen Kommentar den RTD-Namespace von jinja2 in jinja ändern?

In der Version 2.11 denke ich daran, das Paket in jinja umzubenennen, mit einem Platzhaltermodul für jinja2 , das alle Importe weiterleitet und eine veraltete Warnung ausgibt.

Ich muss noch den Zeitpunkt für diesen nächsten Schritt ausarbeiten, aber ich würde auch gerne versuchen, auf PyPI zum Namen "Jinja" zurückzukehren. Ich denke, was ich versuchen würde, ist einen Jinja 2.11-Build zu haben, der den Platzhalter jinja2 , und den Jinja2 2.11-Build nur von jinja>=2.11 abhängig zu machen, oder ein kleines Shim zu haben, das die Installation erklärt den anderen Namen, ohne irgendeinen Code zu knacken. Ich bin bereit, den zusätzlichen Aufwand zu übernehmen, diese Builds für eine Weile synchron zu halten, während wir eine Umstellung durchführen.

@davidism Dies sollte in einer Point-Release nicht passieren. Dies würde Gurke und eine Menge anderer Dinge zerbrechen.

Da ich vorher meinen Segen gegeben habe, möchte ich dies eigentlich etwas qualifizieren. Ich habe einige Magengeschwüre mit dieser Veränderung. Letztendlich denke ich nicht, dass es für Benutzer besonders nützlich ist (es lässt nur ein Zeichen weg), führt einige Bedenken hinsichtlich der Rückwärtsinkompatibilität ein und macht ein Lernen rückgängig, das ich gemacht habe, als Jinja2 ursprünglich veröffentlicht wurde.

Der Grund, warum das Paket in 2.0 umbenannt wurde, war, dass es keine Möglichkeit gab (und es gibt immer noch keine Möglichkeit), parallele Installationen von Python-Bibliotheken zu haben, die im Gegensatz zu Node oder Rust nicht kompatibel sind. Aus diesem Grund denke ich, dass wir früher oder später wieder in eine dumme Situation geraten werden, in der Jinja 4.0 auf pypi "Jinja4" heißen müsste.

Ich denke, während diese Umbenennung einigermaßen in Ordnung ist, halte ich sie im Allgemeinen nicht mehr für eine gute Idee. Ich denke, diese Änderung wäre unbedenklich, wenn das Python-Importsystem Importe mit verschiedenen Versionen unterstützen würde, was ich jedoch aufgegeben habe.

@coleifer Ich habe wirklich keine Ahnung, was Sie vorschlagen, außer "lass uns das einfach rückgängig machen". Wir werden dies nicht als Patch/Bugfix-Release veröffentlichen, daher schätze ich, dass Sie nicht glücklich sind, dass dies in 2.11 landet. Erwartest du, dass wir dafür Jinja 3 veröffentlichen? Das würde noch mehr Probleme in einem Abhängigkeitsbaum verursachen, der mehrere Pakete hat, die von Jinja abhängig sind.

Ehrlich gesagt finde ich dein Verhalten völlig inakzeptabel und hoffe, dass es Konsequenzen hat.

~fwiw wir könnten auch eine neue (Punkt-)Version von jinja2 , die alle jinja reexportiert (dh es ist das Shim). Das funktioniert normalerweise in Rust, wenn Sie mehrere Abhängigkeiten haben, die von einem anderen Paket abhängen. Sie müssten nur jinja2 aktualisieren, damit Pakete, die von jinja2 abhängen, implizit die Typen von jinja .~ dies verwerfen. Genau das macht das Shim. Ich habe keine Ahnung, was die Sorge ist.

@untitaker Interessiert an den Problemen, auf die Sie sich beziehen, wenn die Umbenennung stattdessen in Jinja 3.0 durchgeführt wird. Basierend auf Diskussionen mit @ThiefMaster schien es sinnvoller zu sein, dies in 3.0 zu tun, da dies eine große Änderung darstellt. Wir haben auch über eine 2.12-Version nur für die Umbenennung nachgedacht.

Jinja2 3.0 wäre das Shim und ziehe Jinja 3.0 als Abhängigkeit hinzu.

Das wäre wahrscheinlich in Ordnung, aber es würde die Verwendung des neuen Namens jinja mit Paketen verbieten, die explizit von Jinja2==2.* abhängen. Was den potentiellen Nutzen des Shims einschränkt.

Ja, das war einer meiner ersten Gründe für 2.11. Ich denke, 2.12 vs. 3.0 hängt davon ab, ob die Umbenennung eine größere Änderung darstellt, obwohl jinja2 weiterhin funktioniert und Warnungen vor Veraltung ausgibt. 3.0 war ursprünglich nur eine Hauptversion, weil Python 3 verworfen wurde.

Nach einigen weiteren internen Diskussionen werden wir dies rückgängig machen. Siehe #1131.