Jinja: 'Jinja' 또는 'Jinja2'의 일관된 이름을 결정합니다.

스택 오버플로 태그는 "jinja2"이고 "jinja"는 보이지 않게 변환되는 동의어입니다. 반대를 향한 나의 노력에도 불구하고. (이것은 약 1년 전에 일어난 일입니다.)

이름에서 "2"를 삭제하고 싶습니다. "jinja" PyPI 페이지에 v2 빌드를 추가하기 시작합니다. "jinja2" 가져오기를 중단하고 "jinja" 네임스페이스로 돌아가십시오.

@ThiefMaster @mitsuhiko @untitaker 의견이 있으신가요?

나는 우리가 그렇게 할 수 있다고 생각하지만 나는 개인적으로 3.0 릴리스를 그것에 맞추는 것을 제안할 것입니다.

:+1: 3.0을 기다리는 중입니다.

스택 오버플로 태그는 "jinja2"이고 "jinja"는 보이지 않게 변환되는 동의어입니다. 반대를 향한 나의 노력에도 불구하고. (이것은 약 1년 전에 일어난 일입니다.)

나는 그것을 고칠 수 있습니다.

편집: 예, 할 수 있습니다

미리보기 이름 바꾸기
jinja2는 3486개의 질문에서 제거됩니다.
3486 질문에 jinja가 추가됩니다.
jinja2에 대한 5개의 약속 문서 제안이 jinja 제안으로 이동됩니다.
태그 동의어 매핑 jinja2 → jinja가 생성됩니다.
(이러한 수에는 삭제된 질문이 포함되고 중복되는 태그는 제외됨)

3.0 릴리스 일정은 어떻게 됩니까?

빨리 우리가 더 나은까지 사람들에게 머리를주는 시작 그래서 무엇을 이제 중단 경고를 추가하는 방법에 대한 jinja2 수입에 경고 jinja 우리는 곧 밖으로 V3를 밀어됩니다 수입 jinja 네임스페이스?

@davidism RTD 네임스페이스를 jinja 로 이동할 수 있습니까? 위의 내 의견에 따르면 현재 jinja2 에 있으며 IIRC에서 다른 프로젝트에 대한 RTD 네임스페이스의 정리/소유권 마이그레이션을 주도하고 있었습니까?

어떤 면에서 Jinja2의 마지막 주요 릴리스는 엔진의 대대적인 변경이었습니다. 우리가 깨야 할 더 많은 것들이 있는지 확실하지 않습니다 :D

Jinja v3에 대한 주요 변경 사항 및 이름 통합을 저장하는 것은 나에게 훌륭하게 들립니다. 우리는 우리가 그것에 대해 계획할 수 있는 주요 변경 사항을 찾으려고 노력할 수도 있습니다.

포함된 블록 무시를 허용 하는 잠재적 가능성을 모든 사람에게 상기시키고 싶습니다. 그 문제가 획기적인 변화를 의미할 필요는 없지만 그것이 여러분 모두가 가고자 하는 경로라면 v3 이정표로 해당 문제를 다시 작성/개방하는 것이 제가 하는 방법입니다. 탄젠트 죄송합니다. :) 아마도 우리는 Jinja v3의 이정표를 깨거나 이정표를 논의하기 위해 또 다른 티켓을 만들 수 있습니다.

nudge @davidism - 위의 내 의견에 따라 RTD 네임스페이스를 jinja2에서 jinja로 수정할 수 있습니까?

2.11 릴리스에서 모든 가져오기를 전달하고 사용 중단 경고를 발행하는 jinja2 용 placholder 모듈을 사용하여 패키지 이름을 jinja 로 바꿀 생각입니다.

나는 여전히 이 다음 단계의 타이밍을 해결해야 하지만 PyPI의 "Jinja" 이름으로 다시 이동하려고 합니다. jinja2 자리 표시자를 포함하는 Jinja 2.11 빌드를 만들고 jinja>=2.11 에 의존하도록 Jinja2 2.11 빌드를 만들거나 설치를 설명하는 작은 shim을 사용하려고 합니다. 코드를 깨지 않고 다른 이름. 전환을 관리하는 동안 잠시 동안 이러한 빌드를 동기화 상태로 유지하기 위해 추가 노력을 기울일 용의가 있습니다.

@davidism 이것은 포인트 릴리스에서 발생해서는 안됩니다. 이것은 피클과 다른 많은 것들을 깨뜨릴 것입니다.

내가 실제로 이것을 어느 정도 자격을 갖추기 전에 축복을 주었기 때문입니다. 이 변화로 위궤양이 생겼습니다. 궁극적으로 나는 그것이 사용자에게 특히 유용하다고 생각하지 않습니다(단 하나의 문자만 떨어뜨림). 이전 버전과의 비호환성 문제를 소개하고 Jinja2가 처음 출시되었을 때 배운 내용을 취소합니다.

패키지 이름이 2.0으로 변경된 이유는 노드나 녹과 달리 호환되지 않는 Python 라이브러리를 병렬로 설치할 수 있는 방법이 없었기 때문입니다. 그 때문에 우리는 조만간 Jinja 4.0이 pypi에서 "Jinja4"로 이름을 지정해야 하는 어리석은 상황에 놓이게 될 것이라고 생각합니다.

그래서 나는 이 이름을 바꾸는 것이 다소 괜찮다고 생각하지만 일반적으로 더 이상 그것이 좋은 생각이라고 생각하지 않습니다. Python 가져오기 시스템이 다른 버전의 가져오기를 지원하지만 내가 희망하는 것을 포기했다면 이 변경 사항은 문제가 되지 않을 것이라고 생각합니다.

@coleifer " 이것을 모르겠습니다 . 우리는 이것을 패치/버그 수정 릴리스로 릴리스하지 않을 것이므로 이것이 2.11에 포함되는 것에 만족하지 않으실 것입니다. 이를 위해 Jinja 3를 출시할 예정인가요? 이는 Jinja에 종속된 여러 패키지가 있는 종속성 트리에서 더 많은 문제를 일으킬 수 있습니다.

솔직히 나는 당신의 행동이 완전히 용납될 수 없다고 생각하며 결과가 있기를 바랍니다.

~fwiw 또한 jinja (즉, shim) 전체를 다시 내보내는 jinja2 의 새 (포인트) 버전을 릴리스할 수 있습니다. 다른 패키지에 의존하는 여러 종속성이 있을 때 일반적으로 Rust에서 작동합니다. 당신은 업데이트해야 할 것 jinja2 에 의존 패키지를 만들기 위해 jinja2 암시의 유형 사용 jinja . ~이 폐기합니다. 이것이 바로 심이 하는 일입니다. 걱정거리가 뭔지 모르겠습니다.

@untitaker 대신 Jinja 3.0에서 이름을 바꾸는 것과 관련하여 언급한 문제에 관심이 있습니다. @ThiefMaster와의 논의에

Jinja2 3.0은 shim이 될 것이며 Jinja 3.0을 종속성으로 가져옵니다.

그것은 아마도 괜찮을 것이지만 Jinja2==2.* 에 명시적으로 의존하는 패키지와 함께 새로운 jinja 이름을 사용하는 것을 금지할 것입니다. 이는 심의 잠재적인 유용성을 제한합니다.

네, 그게 제가 2.11을 선택한 첫 번째 이유 중 하나였습니다. 2.12 대 3.0은 jinja2가 계속 작동하고 사용 중단 경고를 발행하더라도 이름 변경이 주요 변경 사항인지를 결정하는 것으로 귀결됩니다. 3.0은 원래 Python 3을 삭제했기 때문에 주요 릴리스만 될 예정이었습니다.

내부적으로 좀 더 논의한 후 이를 되돌릴 것입니다. #1131 참조.