Incompatible zstd/zstandard versions

[opoplawski]

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

/opt/anaconda/envs/mamba/lib/python3.11/site-packages/conda_package_streaming/package_streaming.py:19: UserWarning: zstandard could not be imported. Running without .conda support.
  warnings.warn("zstandard could not be imported. Running without .conda support.")

and

>>> import zstandard
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/anaconda/envs/mamba/lib/python3.11/site-packages/zstandard/__init__.py", line 39, in <module>
    from .backend_c import *  # type: ignore
    ^^^^^^^^^^^^^^^^^^^^^^^^
ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10505 returned by the lib, 10502 hardcoded in zstd headers, 10502 hardcoded in the cext)

Installed packages

zstandard                 0.19.0          py311hbe0fcd7_1    conda-forge
zstd                      1.5.5                hfc55251_0    conda-forge

Environment info

active environment : None
            shell level : 0
       user config file : /export/home/orion-admin/.condarc
 populated config files : /etc/conda/condarc.d/nwra.yml
          conda version : 23.7.4
    conda-build version : not installed
         python version : 3.11.6.final.0
       virtual packages : __archspec=1=x86_64
                          __glibc=2.28=0
                          __linux=4.18.0=0
                          __unix=0=0
       base environment : /opt/anaconda/envs/mamba  (read only)
      conda av data dir : /opt/anaconda/envs/mamba/etc/conda
  conda av metadata url : None
           channel URLs : https://conda.cora.nwra.com/main/linux-64
                          https://conda.cora.nwra.com/main/noarch
          package cache : /var/cache/conda/pkgs
                          /export/home/orion-admin/.conda/pkgs
       envs directories : /opt/anaconda/envs
                          /export/home/orion-admin/conda/envs
                          /export/home/orion-admin/.conda/envs
                          /opt/anaconda/envs/mamba/envs
               platform : linux-64
             user-agent : conda/23.7.4 requests/2.31.0 CPython/3.11.6 Linux/4.18.0-477.21.1.el8_8.x86_64 almalinux/8.8 glibc/2.28
                UID:GID : 30657:30657
             netrc file : None
           offline mode : False

[isuruf]

This was patched, but for some reason you seem to have gotten two incomaptible versions together. I had the same issue. To fix this,

1. install micromamba ("${SHELL}" <(curl -L micro.mamba.pm/install.sh))
2. ~/.local/bin/micromamba install zstd=1.5.5 zstandard=0.21.0 -p /opt/anaconda/envs/mamba

[opoplawski]

Yeah, resetting the versions gets it working again. So going forward there are restrictions in place to keep them in sync? Thanks.

[net20]

I just had this problem after running mamba update mamba with a fresh Mambaforge (23.1.0-1) installation. The underlying problem seems to be that mamba (somehow, I haven't tracked the dependency path) depends on zstd but not on zstandard. So that command updates zstd to 1.5.5 but leaves zstandard on the shipped version, 0.19.0; the installation then can't recover itself because installing compatible versions would require a working zstandard.

A newer Miniforge (23.3.1-1) ships with compatible versions of zstd 1.5.5 and zstandard 0.19.0, but still doesn't depend on zstandard so the problem will recur if any future version of zstd is incompatible with whichever version of zstandard ships with Miniforge, and will affect anyone who foolishly trusts the winget version of Mambaforge (which stopped updating after the Mambaforge/Miniforge merger).

I think the solution is to fix conda's dependencies so that zstandard doesn't get left behind; I don't think that's in scope for zstandard-feedstock. Edit: it appears that by conda 23.10.0 this had been fixed.

[mbargull]

What can we do with the recipe here to avoid recurring issues?

With the current setup, every time a new zstd version is being made available on conda-forge, zstandard would need to be quickly updated.
Otherwise any recipe that depends (directly or transitively) on zstandard but also on builds of other packages that have only been built for the newer zstd version would be broken (e.g., on Bioconda we currently have package builds for python=3.12 built against zstd=1.5.6 (and thus zstd>=1.5.6,<1.6.0a0 dependencies) that are not installable alongside zstandard since its latest version is pinned to zstd=1.5.5).

One "solution" would be to hold up conda-forge's pinning on zstd (i.e., switch from current 1.5 to 1.5.5) until zstandard is updated -- but that is, of course, conceptually not favorable and will also cause other issues (e.g., we'd essentially need to have 1.5.5 builds maintained).
(This would only be a last resort that I don't want us to take; I'm noting it here only in case someone else brings it up.)

---

I haven't looked into zstandard's upstream and recipe sources at all, so can't make suggestions but only defer questions:

1. Do we have sufficient tests in place that would allow us to move the zstd version dependency prior to upstream?
2. Does zstandard have shared libraries that import/export any symbols in case it is built against statically linked zstd?
   If not, is it feasible to built against conda-forge::zstd-static and thus avoid the zstd dependency here.

[mbargull]

There apparently was a previous discussion at #48 (comment) ff. which concluded with #48 (comment) :

zstandard usually makes a new release once there is a new zstd release. For example zstd 1.5.5 came out on April 4 and zstandard 0.21.0 was released on April 16. So, it's a matter of keeping this feedstock up-to-date.

Currently, we have zstd=1.5.6 upstream release on 2024-03-30 and no zstandard release tag following that update.

[isuruf]

Yeah, we can link statically and include the license file.