Decide on a consistent naming of either Jinja or Jinja2

[jeffwidman]

Continuing discussion from https://github.com/pallets/meta/issues/10#issuecomment-209980352

The naming is inconsistent:

• Github repo is jinja
• Pypi package name is jinja2
• Pallets project calls it "Jinja": https://www.palletsprojects.com/p/jinja/
• RTD namespace is jinja2.readthedocs.io
• Pocoo docs (currently the official ones) are "Jinja": http://jinja.pocoo.org/docs/2.9/
• file extensions are sometimes .jinja, .j2, .jinja2... Ansible project currently uses .j2

We should pick either "Jinja" or "Jinja2" and use it everywhere for consistency.

I am open to either, "Jinja" is simpler and shorter, but "Jinja2" has a more distinctive ring to it and less likely to get confused with any other projects.

[davidism]

The Stack Overflow tag is "jinja2", "jinja" is a synonym that gets invisbly converted. Despite my efforts towards the opposite. (This happened a year or so ago.)

I really want to drop the "2" from the name. Start adding v2 builds to the "jinja" PyPI page. Deprecate the "jinja2" import and go back to the "jinja" namespace.

[jeffwidman]

@ThiefMaster @mitsuhiko @untitaker do you guys have opinions?

[mitsuhiko]

I think we can do that but I would personally propose to align the 3.0 release with that.

[ThiefMaster]

👍 on waiting for 3.0.

---

The Stack Overflow tag is "jinja2", "jinja" is a synonym that gets invisbly converted. Despite my efforts towards the opposite. (This happened a year or so ago.)

I may be able to fix that.

Edit: Yes, I can

Rename preview
jinja2 will be removed from 3486 questions
jinja will be added to 3486 questions
5 commitments to jinja2 Documentation proposal will be moved to the jinja proposal
A tag synonym mapping jinja2 → jinja will be created.
(these counts include deleted questions and exclude overlapping tags)

[jeffwidman]

What is the timeline for 3.0 release?

The sooner we start giving folks a heads up the better, so what about adding a deprecation warning now on jinja2 imports and a warning on jinja imports that we will soon be pushing v3 out to the jinja namespace?

[jeffwidman]

@davidism are you able to move the RTD namespace over to jinja? Per my comment above, it's currently under jinja2, and IIRC, you were driving the cleanup/ownership migration of the RTD namespaces for other projects?

[mitsuhiko]

In a way the last major release of Jinja2 was a massive change in the engine. Not even sure if there is more stuff we need to break :D

[nixjdm]

Saving breaking changes and name consolidation for a Jinja v3 sounds great to me. We might as well try to find what breaking changes we can slate for it.

I'd like to remind everyone of a potential one - allowing included block overrides. That issue doesn't have to mean a breaking change, but if that's the route you all want to go, remaking/opening that issue with a v3 milestone is how I'd do it. Sorry for the tangent. :) Perhaps we can make another ticket for discussing what to break / milestone for Jinja v3.

[jeffwidman]

nudge @davidism - per my comment above, are you able to modify the RTD namespace from jinja2 to jinja?

[davidism]

In the 2.11 release, I'm thinking of renaming the package to jinja, with a placholder module for jinja2 that forwards all imports and issues a deprecation warning.

I'll still have to work out the timing of this next step, but I'd also like to try moving back to the "Jinja" name on PyPI. I think what I'd try to do is have a Jinja 2.11 build that includes the jinja2 placeholder, and make the Jinja2 2.11 build just depend on jinja>=2.11, or have a small shim that explains installing the other name without breaking any code. I'm am willing to take on the extra effort of keeping these builds in sync for a while while we manage a transition.

[mitsuhiko]

@davidism this shouldn't happen in a point release. This would break pickle and a bunch of other things.

[mitsuhiko]

Since I gave my blessings before I want to actually qualify this somewhat. I have some stomach ulcers with this change. Ultimately I don't think it's particularly useful for users (it just drops one character), introduces some backwards incompatibility concerns and it undoes a learning I made back when Jinja2 was originally released.

The reason the package renamed with 2.0 was that there was no way (and there still is no way) to have parallel installations of Python libraries that are incompatible unlike node or rust can. Because of that I think we're going to be sooner or later again in a stupid situation where Jinja 4.0 would need to be named "Jinja4" on pypi.

So I think while this rename is somewhat okay I generally don't think anymore that it's a good idea. I think this change would be without concerns if the Python import system were to support imports with different versions which however I gave up hoping for.

[untitaker]

@coleifer I really have no idea what you're suggesting other than "let's just revert this". We won't release this as a patch/bugfix release, so I guess you are not happy that this will land in 2.11. Are you expecting us to release Jinja 3 for this? That would cause even more problems in a dependency tree that has multiple package dependant on Jinja.

Honestly I find your behavior completely unacceptable and hope it will have consequences.

[untitaker]

fwiw we could also release a new (point) version of jinja2 that reexports all of jinja (ie it is the shim). That usually works in Rust when you have multiple dependencies that depend on another package. You'd just have to update jinja2 to make packages that depend on jinja2 implicitly use the types from jinja. discard this. This is exactly what the shim is doing. I have no idea what the concern is.

[davidism]

@untitaker Interested in the issues you refer to with making the rename happen in Jinja 3.0 instead. Based on discussion with @ThiefMaster, it seemed that doing it in 3.0 made more sense, as it does represent a major change. We also thought about a 2.12 release for just the rename.

Jinja2 3.0 would be the shim and pull in Jinja 3.0 as a dependency.

[untitaker]

That would probably be fine but it would prohibit using the new jinja name with packages that explicitly depend on Jinja2==2.*. Which limits the potential usefulness of the shim.

[davidism]

Yeah, that was one of my initial reasons for going with 2.11. I guess 2.12 vs 3.0 comes down to deciding on if the rename is a major change even though jinja2 would continue to work and issue deprecation warnings. 3.0 was originally only going to be a major release because it dropped Python 3.

---

After some more discussion internally, we're reverting this. See #1131.