5 ms·

Why break the existing library instead of making a new one? Concretely, why not do like jinja2 and psycopg2?

by neolog 5y ago

simonw 5y ago
Because then you have to actively maintain two libraries forever instead of one.
- neolog 5y ago
  No I don't, I can always stop maintaining a library. But I don't have to actively break it either.
  - simonw 5y ago
    In that case the maintainer can release version 2.0 and have a note in the README that says "if you don't want the breaking changes in 2.0 here's how to install the last release from the 1.0 series - note that this series is no longer maintained so any bugs or security issues will not be addressed."
- blacktriangle 5y ago
  That's the price of writing maintainable software.
- ajmurmann 5y ago
  Two libraries or two branches. What's the difference?
one_off_comment 5y ago
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?
shadowgovt 5y ago
In one sense, you could. That's just taking the semantically significant information and moving it from the major revision number to the name. But then most systems are going to consider those libraries to be entirely separate, most search engines are going to make it hard to find out about one if you find out about the other, and so on and so forth. Major version number also implies that if you have no reason to choose one over the other, you should be choosing the most recent one.
ajmurmann 5y ago
Any reasonable dependency management tool should allow you to pin down any part of the semver version. For example on regular upgrade only pull patches or minors and require a manual change to upgrade otherwise. Appending a version number to the library name is a heck around completely inadequate dependency management tools. A language not having a tool en par with bundler, cargo or yarn is a massive negative for me when looking at new languages.
crdrost 5y ago
“So I spent a week doing OAuth2 stuff. It took a couple days to read through [Google’s] ten-thousand lines of code, so then I went and looked for other libraries. There's `python-oauth2`... it's the second version of python-oauth, it doesn't actually do OAuth2. But that took a while to figure out. So that one was a little bit better, 540 source lines of code, 15 classes, but I wasn’t going to put that in either because it didn’t actually do what I needed to do. So I rewrote that to just do bearer-token authentication, it’s ‘python-foauth,’ or if you prefer, ‘eff oauth.’” -- Jack Diederich, “Stop Writing Classes”, https://youtube.com/watch?v=o9pEzgHorH0 https://youtube.com/watch?v=o9pEzgHorH0
- neolog 5y ago
  In cases where the name is ambiguous you can use another name like python-oauth-v2.
  - 0xbadcafebee 5y ago
    With CPAN this was solved by hierarchical package/class naming. Net.pm Net/IMAP.pm Net/IMAP/SSL.pm ^ Each of those is published by a different author, and inherits the previous one to add features. As a result CPAN is a tremendously useful library of OO, not because they're all different, but because they are designed to inherit and extend existing code, rather than re-write the whole thing and have 500 differently-named-almost-identical codebases. CPAN's been around for decades, and everybody talks about DRY code, and yet no other language seems to want to actually reuse and extend code.
treesprite82 5y ago
No existing project should break unless its developers take the action to upgrade (bumping the version of the library that the library manager is looking for). The reason I'd personally prefer package 2.0.0 rather than package2 1.0.0 is because a lot of tools understand the former. For example tools can let the user know a breaking update is available, or allow me to specify that my project works with many major releases of package, or upgrade/downgrade more conveniently.
OJFord 5y ago
Because that's really annoying? Boto is (forever now, presumably) v2.x, and Boto3 is on v1.x. How is that helpful?

Why break the existing library instead of making a new one? Concretely, why not do like jinja2 and psycopg2?

by neolog 5y ago

Why break the existing library instead of making a new one? Concretely, why not do like jinja2 and psycopg2?

simonw 5y ago

Because then you have to actively maintain two libraries forever instead of one.

neolog 5y ago
No I don't, I can always stop maintaining a library. But I don't have to actively break it either.
- simonw 5y ago
  In that case the maintainer can release version 2.0 and have a note in the README that says "if you don't want the breaking changes in 2.0 here's how to install the last release from the 1.0 series - note that this series is no longer maintained so any bugs or security issues will not be addressed."
blacktriangle 5y ago
That's the price of writing maintainable software.
ajmurmann 5y ago
Two libraries or two branches. What's the difference?

one_off_comment 5y ago

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?

shadowgovt 5y ago

In one sense, you could. That's just taking the semantically significant information and moving it from the major revision number to the name. But then most systems are going to consider those libraries to be entirely separate, most search engines are going to make it hard to find out about one if you find out about the other, and so on and so forth. Major version number also implies that if you have no reason to choose one over the other, you should be choosing the most recent one.

ajmurmann 5y ago

Any reasonable dependency management tool should allow you to pin down any part of the semver version. For example on regular upgrade only pull patches or minors and require a manual change to upgrade otherwise. Appending a version number to the library name is a heck around completely inadequate dependency management tools. A language not having a tool en par with bundler, cargo or yarn is a massive negative for me when looking at new languages.

crdrost 5y ago

“So I spent a week doing OAuth2 stuff. It took a couple days to read through [Google’s] ten-thousand lines of code, so then I went and looked for other libraries. There's `python-oauth2`... it's the second version of python-oauth, it doesn't actually do OAuth2. But that took a while to figure out. So that one was a little bit better, 540 source lines of code, 15 classes, but I wasn’t going to put that in either because it didn’t actually do what I needed to do. So I rewrote that to just do bearer-token authentication, it’s ‘python-foauth,’ or if you prefer, ‘eff oauth.’” -- Jack Diederich, “Stop Writing Classes”, https://youtube.com/watch?v=o9pEzgHorH0 https://youtube.com/watch?v=o9pEzgHorH0

neolog 5y ago
In cases where the name is ambiguous you can use another name like python-oauth-v2.
- 0xbadcafebee 5y ago
  With CPAN this was solved by hierarchical package/class naming. Net.pm Net/IMAP.pm Net/IMAP/SSL.pm ^ Each of those is published by a different author, and inherits the previous one to add features. As a result CPAN is a tremendously useful library of OO, not because they're all different, but because they are designed to inherit and extend existing code, rather than re-write the whole thing and have 500 differently-named-almost-identical codebases. CPAN's been around for decades, and everybody talks about DRY code, and yet no other language seems to want to actually reuse and extend code.

treesprite82 5y ago

No existing project should break unless its developers take the action to upgrade (bumping the version of the library that the library manager is looking for). The reason I'd personally prefer package 2.0.0 rather than package2 1.0.0 is because a lot of tools understand the former. For example tools can let the user know a breaking update is available, or allow me to specify that my project works with many major releases of package, or upgrade/downgrade more conveniently.

OJFord 5y ago

Because that's really annoying? Boto is (forever now, presumably) v2.x, and Boto3 is on v1.x. How is that helpful?