Jinja: Выберите последовательное наименование Jinja или Jinja2.

Тег переполнения стека - это «jinja2», «jinja» - это синоним, который незаметно конвертируется. Несмотря на мои усилия в направлении противоположного. (Это произошло около года назад.)

Очень хочется убрать цифру "2" из названия. Начните добавлять сборки v2 на страницу PyPI "jinja". Откажитесь от импорта «jinja2» и вернитесь в пространство имен «jinja».

@ThiefMaster @mitsuhiko @untitaker , ребята, у вас есть мнение?

Я думаю, что мы можем это сделать, но я лично предлагаю согласовать выпуск 3.0 с этим.

: +1: в ожидании 3.0.

Тег переполнения стека - это «jinja2», «jinja» - это синоним, который незаметно конвертируется. Несмотря на мои усилия в направлении противоположного. (Это произошло около года назад.)

Возможно, я смогу это исправить.

Изменить: да, я могу

Переименовать предварительный просмотр
jinja2 будет удален из 3486 вопросов
jinja будет добавлено к 3486 вопросам
5 обязательств перед jinja2 Предложение по документации будет перемещено в предложение 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 я подумываю переименовать пакет в jinja с модулем placholder для jinja2 который пересылает весь импорт и выдает предупреждение об устаревании.

Мне все еще нужно определить время для этого следующего шага, но я также хотел бы попробовать вернуться к имени «Jinja» в PyPI. Я думаю, что я бы попытался сделать сборку Jinja 2.11, которая включает заполнитель jinja2 , и сделать сборку Jinja2 2.11 просто зависимой от jinja>=2.11 или иметь небольшую прокладку, объясняющую установку другое имя без нарушения кода. Я готов взять на себя дополнительные усилия по поддержанию синхронизации этих сборок в течение некоторого времени, пока мы управляем переходом.

@davidism этого не должно происходить в точечном выпуске. Это сломает рассол и множество других вещей.

Поскольку я дал свое благословение до того, как я хочу на самом деле несколько уточнить это. Из-за этого изменения у меня несколько язв желудка. В конечном счете, я не думаю, что это особенно полезно для пользователей (он просто отбрасывает один символ), вносит некоторые проблемы с обратной несовместимостью и отменяет обучение, которое я сделал, когда изначально был выпущен Jinja2.

Причина, по которой пакет переименован в 2.0, заключалась в том, что не было возможности (и все еще нет возможности) иметь параллельные установки библиотек Python, которые несовместимы в отличие от node или rust. Из-за этого я думаю, что рано или поздно мы снова окажемся в глупой ситуации, когда Jinja 4.0 нужно будет называть «Jinja4» на pypi.

Так что я думаю, что хотя это переименование в какой-то мере нормально, я больше не думаю, что это хорошая идея. Я думаю, что это изменение не вызвало бы беспокойства, если бы система импорта Python поддерживала импорт с разными версиями, на что, однако, я отказался.

@coleifer Я действительно понятия не имею, что вы предлагаете, кроме «давайте просто

Честно говоря, я считаю ваше поведение совершенно неприемлемым и надеюсь, что оно будет иметь последствия.

~ fwiw мы также могли бы выпустить новую (точечную) версию jinja2 которая реэкспортирует все jinja (т.е. это прокладка). Обычно это работает в Rust, когда у вас есть несколько зависимостей, зависящих от другого пакета. Вам просто нужно обновить jinja2 чтобы пакеты, зависящие от jinja2 неявно использовали типы из jinja . ~ Отбросьте это. Именно это и делает прокладка. Понятия не имею, в чем проблема.

@untitaker Заинтересованы в проблемах, о которых вы говорите, когда переименование происходит в Jinja 3.0. Основываясь на обсуждении с @ThiefMaster , казалось, что делать это в 3.0 имеет больше смысла, поскольку это действительно серьезное изменение. Мы также думали о выпуске 2.12 только для переименования.

Jinja2 3.0 будет прокладкой и потянет Jinja 3.0 в качестве зависимости.

Это, вероятно, было бы хорошо, но это запретило бы использовать новое имя jinja с пакетами, которые явно зависят от Jinja2==2.* . Что ограничивает потенциальную полезность прокладки.

Да, это была одна из первых причин, по которой я выбрал 2.11. Я предполагаю, что 2.12 против 3.0 сводится к решению, является ли переименование серьезным изменением, даже если jinja2 продолжит работать и будет выдавать предупреждения об устаревании. Изначально 3.0 планировался стать основным выпуском только потому, что он отказался от Python 3.

После некоторого внутреннего обсуждения мы возвращаем это. См. №1131.