8 ms·

I feel like most of these problems just disappear if people would follow the same naming scheme sqlite3 uses. Just put the major version in the name and most to

I feel like most of these problems just disappear if people would follow the same naming scheme sqlite3 uses. Just put the major version in the name and most tools just work out of the box with multiple versions.

greener_grass 2y ago
This is Rich Hickey's suggestion too https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk
the_mitsuhiko 2y ago
That’s why I called the library “jinja2”. It was a new major version. But people over the years really did not like it and it did not catch on much.
- smitty1e 2y ago
  Once more, the wisdom of "Explicit is better than implicit" shines. Instead, we jump through hoops with our hair on fire to manage complexity. People.
- TZubiri 2y ago
  Agree. The issue was breaking bc by releasing a new major under the same name.
- rbanffy 2y ago
  Really, people should just update their software to use the newer libraries and fix whatever breaks. If you want to use functions from version 2, you should port the rest of the code to version 2.
bobnamob 2y ago
Of course coming with the _major_ caveat that the interface and behaviour[1] of the dependency is absolutely stable for the entirety of the "major version". I'm an advocate for this style of library/dependency development, unfortunately in my experience the average dependency doesn't have the discipline to pull it off. [1] https://www.hyrumslaw.com https://www.hyrumslaw.com
- zo1 2y ago
  I don't want to "pull this off", nor do I want to expend the time/energy to do so. We're not Microsoft with effectively infinite budgets, nor are we Elasticsearch/Grafana Orgs with metric oodles of developer-hours, and 50k+ github star mindshares-worth of evangelists behind us to document and tutorialize every tiny little feature in a cookbook or doc website. Code changes, and it's kinda silly to expect interfaces to be locked in place as that'll stifle development for even small-ish features. Does that mean every minor version or commit will change fundamental or large parts of the codebase? Probably not, but it's a sliding scale and people seriously need to find something better to do than writing Yet Another Python Package Manager. I use the term "we" loosely here ofc in the context of this mini-rant.
  - andrewchambers 2y ago
    If you are breaking the api it isn't that hard to add a new one instead of butchering the old one. If it really can't be done then you aren't really shipping a library that is meant to be depended on.
benrutter 2y ago
I think this works ok if your library is something like Django or Pandas that people are building their project around. But it makes things exponentially more complex for libraries like pyarrow or fsspec that are normally subdependencies. Imagine trying to do things like import pyarrow14, then if that failed try pyarrow13, etc. Additionally, python doesn't have a good way of saying "I need one of the following different libraries as a dependency"
- andrewchambers 2y ago
  I like the way python handled this situation - python3 for when you care, python for when you don't.
dist-epoch 2y ago
sqlite3 was released 20 years ago, in 2004. I'm not convinced all code written in 2004 which used sqlite3 would still work today against the latest version.
- aragilar 2y ago
  If stuff was removed, then I would have expected them to bump the ABI? As they haven't done that, I would actually assume it would work absent evidence to the contrary?

greener_grass 2y ago

This is Rich Hickey's suggestion too https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk

the_mitsuhiko 2y ago

That’s why I called the library “jinja2”. It was a new major version. But people over the years really did not like it and it did not catch on much.

smitty1e 2y ago
Once more, the wisdom of "Explicit is better than implicit" shines. Instead, we jump through hoops with our hair on fire to manage complexity. People.
TZubiri 2y ago
Agree. The issue was breaking bc by releasing a new major under the same name.
rbanffy 2y ago
Really, people should just update their software to use the newer libraries and fix whatever breaks. If you want to use functions from version 2, you should port the rest of the code to version 2.

bobnamob 2y ago

Of course coming with the _major_ caveat that the interface and behaviour[1] of the dependency is absolutely stable for the entirety of the "major version". I'm an advocate for this style of library/dependency development, unfortunately in my experience the average dependency doesn't have the discipline to pull it off. [1] https://www.hyrumslaw.com https://www.hyrumslaw.com

zo1 2y ago
I don't want to "pull this off", nor do I want to expend the time/energy to do so. We're not Microsoft with effectively infinite budgets, nor are we Elasticsearch/Grafana Orgs with metric oodles of developer-hours, and 50k+ github star mindshares-worth of evangelists behind us to document and tutorialize every tiny little feature in a cookbook or doc website. Code changes, and it's kinda silly to expect interfaces to be locked in place as that'll stifle development for even small-ish features. Does that mean every minor version or commit will change fundamental or large parts of the codebase? Probably not, but it's a sliding scale and people seriously need to find something better to do than writing Yet Another Python Package Manager. I use the term "we" loosely here ofc in the context of this mini-rant.
- andrewchambers 2y ago
  If you are breaking the api it isn't that hard to add a new one instead of butchering the old one. If it really can't be done then you aren't really shipping a library that is meant to be depended on.

benrutter 2y ago

I think this works ok if your library is something like Django or Pandas that people are building their project around. But it makes things exponentially more complex for libraries like pyarrow or fsspec that are normally subdependencies. Imagine trying to do things like import pyarrow14, then if that failed try pyarrow13, etc. Additionally, python doesn't have a good way of saying "I need one of the following different libraries as a dependency"

andrewchambers 2y ago
I like the way python handled this situation - python3 for when you care, python for when you don't.

dist-epoch 2y ago

sqlite3 was released 20 years ago, in 2004. I'm not convinced all code written in 2004 which used sqlite3 would still work today against the latest version.

aragilar 2y ago
If stuff was removed, then I would have expected them to bump the ABI? As they haven't done that, I would actually assume it would work absent evidence to the contrary?