Incompatible zstd/zstandard versions about zstandard-feedstock HOT 6 OPEN

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.

from zstandard-feedstock.

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

from zstandard-feedstock.

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

from zstandard-feedstock.

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

from zstandard-feedstock.

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.

from zstandard-feedstock.

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.

from zstandard-feedstock.