'msgpack-python' egg was renamed 'msgpack'

[jmuchemb]

https://github.com/msgpack/msgpack-python/#very-important-notes-for-existing-users

[mgedmin]

Should I retry the failed Python 3.6 tests to see if they're non-deterministic failures? Or is anyone planning to analyze the failure and would rather I didn't destroy the current logs?

(I don't think Travis can let you see the logs of jobs that you've retried. If I'm mistaken, I'd love to hear a correction!)

[icemac]

@jmuchemb Could you please rebase your PR onto master, as it has now successfully running tests again.

[jmuchemb]

Oh so many failures. We could first require v0.5.6, since the regressions seem to be caused by v0.6.

I have no time to work on ZEO code.

[icemac]

Using a msgpack version < 0.6 fixes the tests.
Can we merge this PR having a follow-up issue to update to the current version or should the issues be fixed in this PR? Any preference?

[jamadden]

If the failures are simple and the fixes obvious, I think it'd be fine to fix them here while also updating the pin.

However, from glancing at the log, neither the failures nor the fixes look simple (to me). In that case, it seems reasonable to merge this simple PR, so that master is working/releasable, and defer the version update to a later PR (so long as there's an issuer so we don't forget).

[icemac]

I created #122 for the update to a current msgpack version.
Should this change have a change log entry or is it now ready to merge?

[jamadden]

It's only a test dependency, so we could probably get away without a change note. On the other hand, it would be good to record somewhere public that (until #122 lands) using the msgpack support requires such-and-such versions of such-and-such dependencies. Changelog lines are cheap, so I would vote for one. But it doesn't seem like a big deal to me.