Jinja: Decidir sobre un nombre consistente de "Jinja" o "Jinja2"

La etiqueta Stack Overflow es "jinja2", "jinja" es un sinónimo que se convierte de forma invisible. A pesar de mis esfuerzos hacia lo contrario. (Esto sucedió hace aproximadamente un año).

Realmente quiero quitar el "2" del nombre. Comience a agregar compilaciones v2 a la página PyPI "jinja". Desactive la importación "jinja2" y vuelva al espacio de nombres "jinja".

@ThiefMaster @mitsuhiko @untitaker ¿ustedes tienen

Creo que podemos hacer eso, pero personalmente propondría alinear la versión 3.0 con eso.

: +1: a la espera de 3.0.

La etiqueta Stack Overflow es "jinja2", "jinja" es un sinónimo que se convierte de forma invisible. A pesar de mis esfuerzos hacia lo contrario. (Esto sucedió hace aproximadamente un año).

Quizás pueda arreglar eso.

Editar: Sí, puedo

Cambiar el nombre de la vista previa
jinja2 se eliminará de 3486 preguntas
jinja se agregará a 3486 preguntas
5 compromisos con la propuesta de documentación jinja2 se trasladarán a la propuesta jinja
Se creará un mapeo de sinónimos de etiquetas jinja2 → jinja.
(estos recuentos incluyen preguntas eliminadas y excluyen etiquetas superpuestas)

¿Cuál es el cronograma para la versión 3.0?

Cuanto antes comencemos a avisar a la gente, mejor, entonces, ¿qué tal si agregamos una advertencia de depreciación ahora en las importaciones de jinja2 y una advertencia en las importaciones de jinja que pronto estaremos impulsando v3 a la jinja espacio

@davidism, ¿puedes mover el espacio de nombres RTD a jinja ? Según mi comentario anterior, actualmente está por debajo de jinja2 , e IIRC, ¿estaba impulsando la migración de limpieza / propiedad de los espacios de nombres RTD para otros proyectos?

En cierto modo, el último lanzamiento importante de Jinja2 fue un cambio masivo en el motor. Ni siquiera estoy seguro de si hay más cosas que necesitemos romper: D

Guardar cambios importantes y la consolidación de nombres para un Jinja v3 me suena genial. También podríamos intentar encontrar qué cambios importantes podemos programar para ello.

Me gustaría recordarles a todos uno potencial: permitir anulaciones de bloque incluidas . Ese problema no tiene por qué significar un cambio importante, pero si esa es la ruta que todos quieren seguir, rehacer / abrir ese problema con un hito v3 es cómo lo haría. Perdón por la tangente. :) Quizás podamos hacer otro ticket para discutir qué romper / hito para Jinja v3.

nudge @davidism : según mi comentario anterior, ¿puedes modificar el espacio de nombres RTD de jinja2 a jinja?

En la versión 2.11, estoy pensando en cambiar el nombre del paquete a jinja , con un módulo placholder para jinja2 que reenvía todas las importaciones y emite una advertencia de obsolescencia.

Aún tendré que calcular el momento de este próximo paso, pero también me gustaría intentar volver al nombre "Jinja" en PyPI. Creo que lo que intentaría hacer es tener una compilación de Jinja 2.11 que incluya el marcador jinja2 posición Jinja2 2.11 solo dependa de jinja>=2.11 , o tener una pequeña corrección que explique la instalación el otro nombre sin descifrar ningún código. Estoy dispuesto a hacer un esfuerzo adicional para mantener estas compilaciones sincronizadas durante un tiempo mientras gestionamos una transición.

@davidism esto no debería suceder en un comunicado puntual. Esto rompería pepinillos y un montón de cosas más.

Dado que di mis bendiciones antes, quiero calificar esto de alguna manera. Tengo algunas úlceras de estómago con este cambio. En última instancia, no creo que sea particularmente útil para los usuarios (solo deja caer un carácter), presenta algunas preocupaciones de incompatibilidad hacia atrás y deshace un aprendizaje que aprendí cuando se lanzó Jinja2 originalmente.

La razón por la que el paquete se renombró con 2.0 fue que no había forma (y todavía no hay forma) de tener instalaciones paralelas de bibliotecas de Python que son incompatibles, a diferencia de lo que ocurre con node o rust. Por eso creo que tarde o temprano nos encontraremos de nuevo en una situación estúpida en la que Jinja 4.0 tendría que llamarse "Jinja4" en pypi.

Así que creo que si bien este cambio de nombre está algo bien, en general ya no creo que sea una buena idea. Creo que este cambio no tendría problemas si el sistema de importación de Python fuera compatible con las importaciones con diferentes versiones que, sin embargo, dejé de esperar.

@coleifer Realmente no tengo idea de lo que estás sugiriendo además de "revertir esto". No publicaremos esto como una versión de parche / corrección de errores, así que supongo que no está contento de que llegue a la 2.11. ¿Esperas que lancemos Jinja 3 para esto? Eso causaría aún más problemas en un árbol de dependencia que tiene varios paquetes dependientes de Jinja.

Honestamente, encuentro su comportamiento completamente inaceptable y espero que tenga consecuencias.

~ fwiw también podríamos lanzar una nueva versión (puntual) de jinja2 que reexporta todo jinja (es decir, es el shim). Eso generalmente funciona en Rust cuando tiene varias dependencias que dependen de otro paquete. Solo tendría que actualizar jinja2 para hacer que los paquetes que dependen de jinja2 usen implícitamente los tipos de jinja . ~ Descarte esto. Esto es exactamente lo que está haciendo la cuña. No tengo idea de cuál es la preocupación.

@untitaker Interesado en los problemas a los que se refiere al hacer que el cambio de nombre ocurra en Jinja 3.0. Según la discusión con @ThiefMaster , parecía que hacerlo en 3.0 tenía más sentido, ya que representa un cambio importante. También pensamos en una versión 2.12 solo para el cambio de nombre.

Jinja2 3.0 sería el complemento y tiraría de Jinja 3.0 como dependencia.

Eso probablemente estaría bien, pero prohibiría el uso del nuevo nombre jinja con paquetes que dependen explícitamente de Jinja2==2.* . Lo que limita la utilidad potencial de la calza.

Sí, esa fue una de mis razones iniciales para elegir 2.11. Supongo que 2.12 vs 3.0 se reduce a decidir si el cambio de nombre es un cambio importante a pesar de que jinja2 continuaría funcionando y emitiría advertencias de obsolescencia. 3.0 originalmente solo iba a ser una versión importante porque eliminó Python 3.

Después de un poco más de discusión interna, vamos a revertir esto. Vea el n. ° 1131.