Hacker News Reader

Comment by seanc | Hacker News Reader

Only to an extent. I can't think of a language environment where each package can have its own version of a dependency. Python certainly isn't one.

So if you want any of the Flask 3.0 features you have to take the new Werkzeug, and see Flask-Login break.

View on HN

Node lets every package have its own versions of dependencies. But, imo, it’s better (less time spent fixing upgrade breakage/incentive to pick stable dependencies) in the long run to depend on latest and always update, fixing breakage as you go and only locking versions in CI so you can deploy a known bundle.

Of "Frequently update dependencies to latest" or "don't have to modify code which depends on others", you only get to pick one.

If you're frequently updating to latest, you're on the bleeding edge; sometimes things will bleed more than others.

If you're stable, you might not have the latest and greatest all the time.

The attitude of expecting to always have the latest and greatest, but never have anything break, all while not paying for the effort, seems absurd to me.

It works pretty well, it’s like how continuous integration seemed absurd to people who spent months integrating changes and now is the standard practice.

Anyways, in my experience, if you routinely use the latest and greatest versions of dependencies, over time you find that you stop using dependencies that make this painful.

Anyways, I’m fine with accidental breakage. Deliberately choosing instability in the form of a major version release seems irresponsible for packages at the base of an entire ecosystem. (Absent some critical security issue that your users would have to address anyways as happened with log4j)

Rust (Cargo) supports this.

Reply on news.ycombinator.com