Avoid version mismatch warning about benchmarks HOT 3 CLOSED

I don't full understand the proposal, and I'm going to ask some questions that show I don't know much about this. Hope you don't mind.

Sometimes things blow up if you have different versions of something on client/scheduler/worker. Is that only true for a well-defined set of packages, so that version mismatches for other packages are fine? Or could any package X (in principle) cause bad things if you have version mismatch? If in principle anything could be a problem, then is the proposal to pin everything in the dependency tree?

Would we monitor everything pinned/everything in the dependency tree and release a new version of coiled-runtime to bump pins whenever there's a security patch (non-trivial bug fix?) in a dependency? (Not sure how often things in our dependencies have security patches since I'm not a full-time resident of this part of the python ecosystem, but this sounds like a non-trivial responsibility.) If so, would we recommend that customers not pin to patch version of coiled-runtime (and we'd do sufficient testing to be moderately confident that patch updates won't break stuff)?

from benchmarks.

I'm generally in support of this idea, since I believe it will lead to a much smoother user experience. The only potential drawbacks I can see would be the desire to allow coiled to float.

This would mean that, for the life of any supported coiled-runtime release, coiled will be constrained by that dependency.

@ntabris -- there is additional burden, But it seems like that burden exists regardless; this just makes it explicit. Thoughts?

from benchmarks.

Is that only true for a well-defined set of packages, so that version mismatches for other packages are fine? Or could any package X (in principle) cause bad things if you have version mismatch?

Any package version mismatch could lead to things failing. Distributed will check a few libraries (e.g. Python, dask, distributed, etc.) that are common offenders for causing things to fail and emit a warning is one of those packages has a version mismatch. That doesn't mean things can't go wrong due to other packages, but does help in lots of common cases.

If in principle anything could be a problem, then is the proposal to pin everything in the dependency tree?

I'm just proposing we pin the specific packages distributed checks by default (which I think are all dependencies of distributed) to make sure coiled-runtime users don't get a red warning message

Would we monitor everything pinned/everything in the dependency tree and release a new version of coiled-runtime to bump pins whenever there's a security patch (non-trivial bug fix?) in a dependency?

I'm not too concerned about security patches here. For this part of the Python stack they have been historically very rare. We're still determining our version scheme and can factor this point in when making a final decision

This would mean that, for the life of any supported coiled-runtime release, coiled will be constrained by that dependency.

Fair point, I'll have to look at the coiled dependencies to get a sense for how much of an issue this may be

from benchmarks.