4 ms·

What's the difference? It's not like the old version of the library ceases to exist. What's the difference between jinja 2.0 and jinja2 1.0?

wccrawford 5y ago
IMO, the difference between those 2 should be that jinja2 1.0 should be a complete rewrite, possibly in a different language, and probably even a mental shift in working with it.
deleted 5y ago
[deleted]
neolog 5y ago
The difference is whether you break old code for users.
- Stampo00 5y ago
  Both would break old code for users. If you don't want to update your code don't update your dependency.
  - neolog 5y ago
    No, installing jinja2 doesn't break my jinja-using code. Installing 2.0 does.
    - one_off_comment 5y ago
      That sounds like a package manager/module system issue, not a library issue. A sound system would let you use both as long as you weren't ambiguous with your imports.
simonw 5y ago
The difference is tooling. Tools like Dependabot know that Jinja 2.0 is a major release of Jinja. They have no way of knowing that a package with a separate name is related to the first one.
- neolog 5y ago
  The problem is that the two incompatible packages are only weakly "related": they're just two packages in the same space that may share some authors. What if I want to use code from both packages?
  - simonw 5y ago
    Yeah that's a reason in most languages to go with the separate package names. As a maintainer I'd much rather not have to put in that extra work just for the tiny minority of my users who might someday want to run two versions of my library in the same project.
badsectoracula 5y ago
Someone who cares about not breaking others' code can keep working on the existing project by fixing bugs, adding new features and even make a "2.0" version that remains backwards compatible.
nonameiguess 5y ago
The practical upshot is: 1) Many Python applications are not pinning dependencies, and even if you are personally, if jinja is a transitive dependency you might pull in a breaking change. You can't if the new package has a different name. 2) You can more easily simultaneously use both to gradually transition your code to use the new API. I don't believe Python package managers have any built-in way to use an "all" conflict manager like Apache Ivy, so you need a different name to enable this.
- Zababa 5y ago
  That sounds like limitations of Python rather than an universal thing.

wccrawford 5y ago

IMO, the difference between those 2 should be that jinja2 1.0 should be a complete rewrite, possibly in a different language, and probably even a mental shift in working with it.

deleted 5y ago

[deleted]

neolog 5y ago

The difference is whether you break old code for users.

Stampo00 5y ago
Both would break old code for users. If you don't want to update your code don't update your dependency.
- neolog 5y ago
  No, installing jinja2 doesn't break my jinja-using code. Installing 2.0 does.
  - one_off_comment 5y ago
    That sounds like a package manager/module system issue, not a library issue. A sound system would let you use both as long as you weren't ambiguous with your imports.

simonw 5y ago

The difference is tooling. Tools like Dependabot know that Jinja 2.0 is a major release of Jinja. They have no way of knowing that a package with a separate name is related to the first one.

neolog 5y ago
The problem is that the two incompatible packages are only weakly "related": they're just two packages in the same space that may share some authors. What if I want to use code from both packages?
- simonw 5y ago
  Yeah that's a reason in most languages to go with the separate package names. As a maintainer I'd much rather not have to put in that extra work just for the tiny minority of my users who might someday want to run two versions of my library in the same project.

badsectoracula 5y ago

Someone who cares about not breaking others' code can keep working on the existing project by fixing bugs, adding new features and even make a "2.0" version that remains backwards compatible.

nonameiguess 5y ago

The practical upshot is: 1) Many Python applications are not pinning dependencies, and even if you are personally, if jinja is a transitive dependency you might pull in a breaking change. You can't if the new package has a different name. 2) You can more easily simultaneously use both to gradually transition your code to use the new API. I don't believe Python package managers have any built-in way to use an "all" conflict manager like Apache Ivy, so you need a different name to enable this.

Zababa 5y ago
That sounds like limitations of Python rather than an universal thing.