I think #poetry gives some bad advice on #python dependency pins: https://python-poetry.org/docs/faq/#why-are-unbound-version-constraints-a-bad-idea
Pessimistic pins like this plunge your consumers into dependency hell when packages update to consume fresh versions of their shared dependencies at different rates. If package Foo needs a new feature from click 8, and package Bar says "well, I work with click 7, better not try click 8" and never releases again, I'm hosed, even if Bar works fine with new click.
Your users should rely on CI, not #semver.
@tim Is the scenario you're describing in Python avoidable in general? I was under the impression that if my app depends on modules A and B, and they both depend on C, but A depends on Cv1 and B depends on Cv2, I'm just screwed because Python's module infrastructure *itself* demands all the packages it sees be at the same version.
(Contrast with npm, where dependencies load their own shadow copies of their dependencies and eventually a compilation / tree-shake process renames the different-versioned copies of the libraries so they can live in the same resulting codebase).
@mtomczak Oh, no, in the presence of an actual conflict, you're still in trouble. But IME the more common case is that there isn't really a conflict, as in:
- A releases when C is at v1.2.3, and, following "best practice," sets an anticipatory ceiling constraint like C >=1.2.3,<2
- C releases v2.0. The previously released A works with the new version of C without changes.
- A doesn't ship a release for a year... and maybe doesn't bother to update their unnecessary C ceiling when they do...