fix zstd/zstandard import error

[imkumarg]

Description:

The _zmsgpack.py (kartothek.core.cube) uses zstd module for the compressor and decompressor technique. I have updated the requirements.txt with the module name.

• Closes The build failure of https://travis-ci.com/github/JDASoftwareGroup/kartothek_hive_integration_test/builds/213539032

[fjetter]

There are two packages for the zstd compression lib in python

https://github.com/indygreg/python-zstandard

and

https://github.com/sergey-dryabzhinsky/python-zstd

and we're using the first one. Installing both can have non trivial side effects.

The release notes of zstandard==0.15.0 mention already that some modules are no longer available in the zstandard module any longer but rather in zstd therefore I would like to change the import in our module accordingly instead of adding a redundant dependency

See also #392

[imkumarg]

So instead, I have to modify the usage of zstd accordingly in the codebase.

[hoffmann]

@fjetter is it an option to downpin zstandard in this tests until #392 is fixed?

[lr4d]

From the zstandard docs

There will be some backwards incompatible changes before 1.0, probably in the 0.9 release. This may involve renaming the main module from zstd to zstandard and renaming various types and methods. Pin the package version to prevent unwanted breakage when this change occurs!

[lr4d]

I think the easiest way forward here is using this commit d8f4c22 (#392)
Otherwise, we can also downpin zstandard.

[imkumarg]

I think the easiest way forward here is using this commit d8f4c22 (#392)
Otherwise, we can also downpin zstandard.

Yes I think too, we can use this commit [d8f4c22 (#392)]

[fjetter]

Haven't tried downpinning and I do not know why tests do not detect this. However, I do not feel comfortable with installing both zstandard libs. I think reusing d8f4c22 is the proper way to go. The other PR is also supposed to deal with the doc build issues since the doc builds are also failing for some other reason

[lr4d]

I do not know why tests do not detect this

@imkumarg Could you include a test for this so that the test would fail before applying d8f4c22 (#392) and would pass afterwards?

[lr4d]

Looks good. Please add a changelog entry

[imkumarg]

Looks good. Please add a changelog entry

Sure I will make the changes.

[dhumil-agarwal-by]

Looks good.

[lr4d]

We can merge this now to fix the issue downstream, but I would still like to see a test for this so that we don't run into this or a similar issue next time.

[lr4d]

Ah, I just figured out why we weren't seeing this in our CI: zstandard is available up to 0.15.1 on PyPI but only up to 0.14.1 on conda-forge (what we're using in our CI).
So, the only way we could "test" this would have been to have a pip env in our tests

[xhochy]

The conda package has been updated, would be nice to get people fix this when I don't have the time ;)

[xhochy]

Can we have a release with this fix?