Jinja: Décidez d'un nom cohérent pour « Jinja » ou « Jinja2 »

La balise Stack Overflow est "jinja2", "jinja" est un synonyme qui est converti de manière invisible. Malgré mes efforts dans le sens inverse. (Cela s'est produit il y a environ un an.)

Je veux vraiment supprimer le "2" du nom. Commencez à ajouter des builds v2 à la page PyPI "jinja". Abandonnez l'importation "jinja2" et revenez à l'espace de noms "jinja".

@ThiefMaster @mitsuhiko @untitaker avez-vous des opinions ?

Je pense que nous pouvons le faire, mais je proposerais personnellement d'aligner la version 3.0 avec cela.

:+1: en attendant 3.0.

La balise Stack Overflow est "jinja2", "jinja" est un synonyme qui est converti de manière invisible. Malgré mes efforts dans le sens inverse. (Cela s'est produit il y a environ un an.)

Je peux peut-être y remédier.

Edit : oui je peux

Renommer l'aperçu
jinja2 sera supprimé de 3486 questions
jinja sera ajouté à 3486 questions
5 engagements envers jinja2 La proposition de documentation sera déplacée vers la proposition jinja
Un mappage de synonyme de balise jinja2 → jinja sera créé.
(ces nombres incluent les questions supprimées et excluent les balises qui se chevauchent)

Quel est le calendrier de la version 3.0 ?

Plus tôt nous commençons à avertir les gens, mieux c'est, alors pourquoi ne pas ajouter un avertissement de dépréciation maintenant sur les importations de jinja2 et un avertissement sur les importations de jinja que nous allons bientôt pousser la v3 vers le jinja espace

@davidism êtes-vous capable de déplacer l'espace de noms RTD vers jinja ? D'après mon commentaire ci-dessus, il est actuellement inférieur à jinja2 , et IIRC, vous conduisiez la migration de nettoyage/propriété des espaces de noms RTD pour d'autres projets ?

D'une certaine manière, la dernière version majeure de Jinja2 était un changement massif dans le moteur. Je ne sais même pas s'il y a plus de choses que nous devons casser :D

Enregistrer les changements de rupture et la consolidation des noms pour un Jinja v3 me semble très bien. Nous pourrions aussi bien essayer de trouver les changements de rupture que nous pouvons lui proposer.

J'aimerais rappeler à tout le monde un potentiel - permettant les remplacements de blocs inclus . Ce problème ne signifie pas nécessairement un changement radical, mais si c'est la voie que vous voulez tous suivre, refaire/ouvrir ce problème avec un jalon v3 est la façon dont je le ferais. Désolé pour la tangente. :) Peut-être pouvons-nous créer un autre ticket pour discuter de ce qu'il faut franchir / jalon pour Jinja v3.

nudge @davidism - selon mon commentaire ci-dessus, êtes-vous en mesure de modifier l'espace de noms RTD de jinja2 à jinja ?

Dans la version 2.11, je pense renommer le package en jinja , avec un module placholder pour jinja2 qui transmet toutes les importations et émet un avertissement de dépréciation.

Je devrai encore déterminer le timing de cette prochaine étape, mais j'aimerais également essayer de revenir au nom "Jinja" sur PyPI. Je pense que ce que j'essaierais de faire, c'est d'avoir une version Jinja 2.11 qui inclut l'espace réservé jinja2 , et de faire dépendre la version Jinja2 2.11 de jinja>=2.11 , ou d'avoir une petite cale qui explique l'installation l'autre nom sans casser aucun code. Je suis prêt à faire l'effort supplémentaire de garder ces versions synchronisées pendant un certain temps pendant que nous gérons une transition.

@davidism, cela ne devrait pas se produire dans une version ponctuelle. Cela briserait le cornichon et un tas d'autres choses.

Puisque j'ai donné mes bénédictions avant, je veux en fait nuancer cela quelque peu. J'ai des ulcères d'estomac avec ce changement. En fin de compte, je ne pense pas que ce soit particulièrement utile pour les utilisateurs (cela ne fait que supprimer un caractère), introduit des problèmes d'incompatibilité en amont et annule un apprentissage que j'ai fait lors de la sortie initiale de Jinja2.

La raison pour laquelle le package a été renommé avec 2.0 était qu'il n'y avait aucun moyen (et il n'y a toujours aucun moyen) d'avoir des installations parallèles de bibliothèques Python qui sont incompatibles contrairement à node ou rust. À cause de cela, je pense que nous allons tôt ou tard nous retrouver dans une situation stupide où Jinja 4.0 devrait être nommé "Jinja4" sur pypi.

Donc, je pense que même si ce changement de nom est plutôt correct, je ne pense généralement plus que ce soit une bonne idée. Je pense que ce changement serait sans souci si le système d'importation Python prenait en charge les importations avec différentes versions, ce que j'ai cependant renoncé à espérer.

@coleifer, je n'ai vraiment aucune idée de ce que vous suggérez, à part "revenons-en là". Nous ne publierons pas cela en tant que version de correctif/correction de bogues, donc je suppose que vous n'êtes pas heureux que cela débarque en 2.11. Vous attendez-vous à ce que nous sortions Jinja 3 pour cela ? Cela causerait encore plus de problèmes dans un arbre de dépendances qui a plusieurs packages dépendants de Jinja.

Honnêtement, je trouve votre comportement totalement inacceptable et j'espère qu'il aura des conséquences.

~fwiw, nous pourrions également sortir une nouvelle version (point) de jinja2 qui réexporte tous les jinja (c'est-à-dire que c'est le shim). Cela fonctionne généralement dans Rust lorsque vous avez plusieurs dépendances qui dépendent d'un autre package. Vous auriez juste à mettre à jour jinja2 pour que les packages qui dépendent de jinja2 utilisent implicitement les types de jinja .~ jetez ceci. C'est exactement ce que fait la cale. Je n'ai aucune idée du souci.

@untitaker Intéressé par les problèmes auxquels vous faites référence pour que le changement de nom se produise à la place dans Jinja 3.0. D'après les discussions avec @ThiefMaster , il semblait que le faire en 3.0 était plus logique, car cela représente un changement majeur. Nous avons également pensé à une version 2.12 juste pour le renommer.

Jinja2 3.0 serait la cale et tirerait Jinja 3.0 en tant que dépendance.

Ce serait probablement bien, mais cela interdirait d'utiliser le nouveau nom jinja avec des packages qui dépendent explicitement de Jinja2==2.* . Ce qui limite l'utilité potentielle de la cale.

Oui, c'était l'une des premières raisons pour lesquelles j'ai opté pour la 2.11. Je suppose que 2.12 vs 3.0 revient à décider si le changement de nom est un changement majeur, même si jinja2 continuerait à fonctionner et à émettre des avertissements de dépréciation. 3.0 n'allait à l'origine être qu'une version majeure car elle a abandonné Python 3.

Après quelques discussions supplémentaires en interne, nous revenons à cela. Voir #1131.