Jinja: Decida sobre uma nomenclatura consistente de `Jinja` ou` Jinja2`

A tag Stack Overflow é "jinja2", "jinja" é um sinônimo que é convertido invisivelmente. Apesar de meus esforços para o oposto. (Isso aconteceu há cerca de um ano.)

Eu realmente quero tirar o "2" do nome. Comece a adicionar compilações v2 à página PyPI "jinja". Cancele a importação "jinja2" e volte para o namespace "jinja".

@ThiefMaster @mitsuhiko @untitaker vocês têm opiniões?

Acho que podemos fazer isso, mas eu pessoalmente proporia alinhar a versão 3.0 com isso.

: +1: em espera por 3.0.

A tag Stack Overflow é "jinja2", "jinja" é um sinônimo que é convertido invisivelmente. Apesar de meus esforços para o oposto. (Isso aconteceu há cerca de um ano.)

Posso ser capaz de consertar isso.

Edit: Sim, eu posso

Renomear visualização
jinja2 será removido de 3486 questões
jinja será adicionado a 3486 questões
5 compromissos para jinja2 A proposta de documentação será movida para a proposta jinja
Um sinônimo de tag mapeando jinja2 → jinja será criado.
(essas contagens incluem perguntas excluídas e excluem tags sobrepostas)

Qual é o cronograma para o lançamento 3.0?

Quanto mais cedo começarmos a avisar as pessoas, melhor, então que tal adicionar um aviso de suspensão de uso agora em jinja2 importações e um aviso em jinja importações de que em breve estaremos empurrando v3 para jinja namespace?

@davidism, você é capaz de mover o namespace RTD para jinja ? De acordo com meu comentário acima, está atualmente abaixo de jinja2 , e IIRC, você estava conduzindo a migração de limpeza / propriedade dos namespaces RTD para outros projetos?

De certa forma, o último grande lançamento do Jinja2 foi uma grande mudança no motor. Nem tenho certeza se há mais coisas que precisamos quebrar: D

Salvar alterações importantes e consolidação de nome para um Jinja v3 parece ótimo para mim. Podemos também tentar encontrar as mudanças significativas que podemos prever.

Eu gostaria de lembrar a todos sobre um potencial - permitindo substituições de bloqueio incluídas . Esse problema não precisa significar uma alteração significativa, mas se esse é o caminho que todos desejam seguir, refazer / abrir esse problema com um marco da v3 é como eu o faria. Desculpe pela tangente. :) Talvez possamos fazer outro tíquete para discutir o que quebrar / marco para Jinja v3.

nudge @davidism - de acordo com meu comentário acima, você é capaz de modificar o namespace RTD de jinja2 para jinja?

Na versão 2.11, estou pensando em renomear o pacote para jinja , com um módulo placholder para jinja2 que encaminha todas as importações e emite um aviso de depreciação.

Ainda terei que definir o momento desta próxima etapa, mas também gostaria de tentar voltar para o nome "Jinja" no PyPI. Acho que tentaria fazer uma compilação Jinja 2.11 que incluísse o marcador de posição jinja2 e fazer a compilação Jinja2 2.11 depender apenas de jinja>=2.11 ou ter um pequeno shim que explica a instalação o outro nome sem quebrar nenhum código. Estou disposto a fazer um esforço extra para manter essas compilações em sincronia por um tempo enquanto gerenciamos uma transição.

@davidism isso não deve acontecer em um lançamento pontual. Isso quebraria picles e um monte de outras coisas.

Já que dei minhas bênçãos antes, quero realmente qualificar isso um pouco. Eu tenho algumas úlceras estomacais com essa mudança. No final das contas, não acho que seja particularmente útil para os usuários (ele apenas descarta um caractere), introduz algumas preocupações de incompatibilidade com versões anteriores e desfaz um aprendizado que fiz quando Jinja2 foi lançado originalmente.

O motivo do pacote renomeado para 2.0 foi que não havia como (e ainda não há) instalações paralelas de bibliotecas Python que são incompatíveis ao contrário do node ou rust can. Por causa disso, acho que mais cedo ou mais tarde estaremos em uma situação estúpida em que Jinja 4.0 precisaria ser nomeado "Jinja4" no pypi.

Então eu acho que embora essa renomeação seja um pouco boa, geralmente não acho mais que seja uma boa ideia. Acho que essa mudança seria sem preocupações se o sistema de importação do Python fosse compatível com importações com versões diferentes, o que, entretanto, desisti de esperar.

@coleifer Eu realmente não tenho ideia do que você está sugerindo além de "vamos apenas reverter isso". Não vamos lançar isso como um lançamento de patch / correção de bug, então eu acho que você não está feliz que isso vá pousar na versão 2.11. Você está esperando que lancemos Jinja 3 para isso? Isso causaria ainda mais problemas em uma árvore de dependências que tem vários pacotes dependentes de Jinja.

Honestamente, acho seu comportamento totalmente inaceitável e espero que tenha consequências.

~ fwiw também poderíamos lançar uma nova versão (pontual) de jinja2 que reexporta tudo de jinja (ou seja, é o shim). Isso geralmente funciona no Rust quando você tem várias dependências que dependem de outro pacote. Você apenas teria que atualizar jinja2 para fazer os pacotes que dependem de jinja2 usarem implicitamente os tipos de jinja . ~ Descartá-los. Isso é exatamente o que o shim está fazendo. Não tenho ideia de qual é a preocupação.

@untitaker Interessado nos problemas aos quais você se refere para fazer a renomeação acontecer no Jinja 3.0. Com base na discussão com @ThiefMaster , parecia que fazer isso no 3.0 fazia mais sentido, pois representa uma grande mudança. Também pensamos em uma versão 2.12 apenas para renomear.

Jinja2 3.0 seria o shim e puxar em Jinja 3.0 como uma dependência.

Provavelmente não haveria problema, mas proibiria o uso do novo jinja name com pacotes que dependem explicitamente de Jinja2==2.* . O que limita a utilidade potencial do calço.

Sim, essa foi uma das minhas razões iniciais para ir com o 2.11. Eu acho que 2,12 vs 3,0 se resume a decidir se renomear é uma mudança importante, embora jinja2 continue a funcionar e emitir avisos de depreciação. 3.0 originalmente só seria um grande lançamento porque abandonou o Python 3.

Depois de mais alguma discussão interna, estamos revertendo isso. Veja # 1131.