Open opoplawski opened 11 months ago
This was patched, but for some reason you seem to have gotten two incomaptible versions together. I had the same issue. To fix this,
"${SHELL}" <(curl -L micro.mamba.pm/install.sh)
)~/.local/bin/micromamba install zstd=1.5.5 zstandard=0.21.0 -p /opt/anaconda/envs/mamba
Yeah, resetting the versions gets it working again. So going forward there are restrictions in place to keep them in sync? Thanks.
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.
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:
zstd
version dependency prior to upstream?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.There apparently was a previous discussion at https://github.com/conda-forge/zstandard-feedstock/pull/48#issuecomment-1645405835 ff. which concluded with https://github.com/conda-forge/zstandard-feedstock/pull/48#issuecomment-1652153971 :
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.
Yeah, we can link statically and include the license file.
Solution to issue cannot be found in the documentation.
Issue
and
Installed packages
Environment info