Get rid of unnecessary version constraints #1093

2021-07-05T23:20:39Z

itamarst commented

2021-07-05 23:20:39 +00:00

(Migrated from github.com)

Fixes https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3390
Fixes https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3404
Fixes https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3723

Fixes https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3390 Fixes https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3404 Fixes https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3723

coveralls commented

2021-07-06 00:18:06 +00:00

(Migrated from github.com)

Coverage increased (+0.007%) to 95.479% when pulling 6475b44336 on 3390.3404.3723-dependency-versions into ed52e43a4a on master.

[![Coverage Status](https://coveralls.io/builds/41131080/badge)](https://coveralls.io/builds/41131080) Coverage increased (+0.007%) to 95.479% when pulling **6475b4433688492c5e4fdbd2a4cf1a7e1733d734 on 3390.3404.3723-dependency-versions** into **ed52e43a4a697a6d3d89c898dda585d1e7e4e76c on master**.

sajith (Migrated from github.com) approved these changes 2021-07-06 02:01:32 +00:00

sajith (Migrated from github.com) left a comment

LGTM!

Open version bounds make me nervous. On the other hand, we've mostly been bitten by libraries transitioning from Python 2 to Python 3. I suppose that kind of breakage will not be a problem going forward. :-)

LGTM! Open version bounds make me nervous. On the other hand, we've mostly been bitten by libraries transitioning from Python 2 to Python 3. I suppose _that_ kind of breakage will not be a problem going forward. :-)

itamarst commented

2021-07-06 16:08:00 +00:00

(Migrated from github.com)

Open version bounds are a good default for libraries, otherwise:

Library X says "I want D with version > 2 and version < 2.1"
Library Y says "I want D with version > 2.1 and version < 2.2"

Now if an application wants to use X and Y... it can't, even though D 2.2 may well be completely backwards compatible.

It's true this can cause breakage occasionally, but at least it's breakage users can fix themselves; in the above scenario, they can't fix without forking X or Y. This in fact is what happened to Tahoe: Tahoe needed version of attrs that was less than version V, and that broke a dependency that needed newer attrs.

What to do when dependencies do backwards incompatible things? Ideally you have all tests run twice: once with oldest supported dependencies, once with latest dependencies. And you run tests daily. And then if there's new release of dependencies that breaks things, that's fine.

Now, to be fair, Tahoe is an application, not a library, so that's a little different. For an application, you want to have two lists of dependencies: minimal direct dependencies (e.g. Twisted > 20.1), and pinned transitive dependencies (Twisted + all the things Twisted depends on, and the dependencies' dependencies, pinned to exact versions) for the distributed package. And then each install gives the exact set of dependencies each time.

This particular configuration is not the transitive pinned dependencies, though, so it shouldn't be too constrained.

Open version bounds are a good default for libraries, otherwise: 1. Library X says "I want D with version > 2 and version < 2.1" 2. Library Y says "I want D with version > 2.1 and version < 2.2" Now if an application wants to use X and Y... it can't, even though D 2.2 may well be completely backwards compatible. It's true this can cause breakage occasionally, but at least it's breakage users can fix themselves; in the above scenario, they can't fix without forking X or Y. This in fact is what happened to Tahoe: Tahoe needed version of attrs that was less than version V, and that broke a dependency that needed newer attrs. What to do when dependencies do backwards incompatible things? Ideally you have all tests run twice: once with oldest supported dependencies, once with latest dependencies. And you run tests daily. And then if there's new release of dependencies that breaks things, that's fine. Now, to be fair, Tahoe is an application, not a library, so that's a little different. For an application, you want to have two lists of dependencies: minimal direct dependencies (e.g. `Twisted > 20.1`), and pinned transitive dependencies (Twisted + all the things Twisted depends on, and the dependencies' dependencies, pinned to _exact_ versions) for the distributed package. And then each install gives the exact set of dependencies each time. This particular configuration is not the transitive pinned dependencies, though, so it shouldn't be too constrained.

👍 1

Sign in to join this conversation.

No reviewers

sajith