Thanks for handling this @jrbourbeau

CI has passed against both msgpack 1.0 and a pre-1.0 release to check for backwards compatibility

I've also set 0.6.0 as the minimum supported msgpack version (released in Nov 2018) because that's when the strict_map_key option was added. This seems reasonable to me, but if there's reason to think this 0.6.0 restriction is too aggressive we can add some additional logic surrounding the msgpack version to support older versions too

Requiring>=0.6 sounds fine.

Great, I just set the minimum version for our CI environments and will merge this PR when the current set of CI builds pass

The test failure seems unrelated and I've raised a separate issue for it (xref #3498)

May I suggest a new build/build number on conda-forge that update the metadata info to pin msgpack to <1.0.0 ? I've read recently that there should be a simpler way to do that via repodata patch, but I haven't used that before.

A PR to the conda-forge feedstock to do that would be welcome 🙂

A PR to the conda-forge feedstock to do that would be welcome 🙂

Do you know how to patch the repodata, or do I just bump the build number ?

See conda-forge/distributed-feedstock#114

Thanks for doing that. Merged! 😄

Do you know how to patch the repodata, or do I just bump the build number ?

Ah sorry missed this bit.

The patches live here. Though bumping the build number works also and may be a bit more straightforward.

Thanks for updating the conda-forge recipe @Carreau!

Jakirkham, I'm more thinking that all previous version of distributed (or at least a few of those) should get msgpack<1;
Bumping the build only affect latest one. It's something that I think will come up more and more often to update dependencies compat after the releases. Hence why I was thinking about repodata patch.

Yeah hot-fixing would still be appropriate Matthias 🙂