BUG: mamba does not apply repodata patches for already-downloaded packages #4156
Description
Troubleshooting docs
- My problem is not solved in the Troubleshooting docs
Anaconda default channels
- I do NOT use the Anaconda default channels (pkgs/* etc.)
How did you install Mamba?
Mambaforge or latest Miniforge
Search tried in issue tracker
done
Latest version of Mamba
- My problem is not solved with the latest version
Tried in Conda?
I do not have this problem with Conda, just with Mamba
Describe your issue
I updated my build environment as usual after some relevant new release using mamba update --all. The update in question was conda-smithy 3.54.1 -> conda-smithy 3.54.2, but as it turns out, py-rattler had a release more or less at the same time, which ended up breaking smithy: conda/rattler#2023
So I downgraded to py-rattler <0.22 locally in order to be able to keep working, while also pushing various fixes
- avoid py-rattler 0.22 due to regression conda-forge/conda-smithy-feedstock#369
- avoid py-rattler v0.22 for newest smithy conda-forge/conda-forge-repodata-patches-feedstock#1140
- Dependency fixes conda-forge/conda-smithy#2454
Now that conda{,-build} 26.1 came out, I did mamba update --all again, and ran into the same breakage (because I hadn't noticed that mamba had wrongly updated to py-rattler v0.22 again). Only this time, the repodata patch should have forbidden mamba updating py-rattler even for the _0 build of conda smithy 3.54.2 I had already installed.
This is certainly not ideal, but could perhaps be written off as transitory. However, if I now try mamba update --all again (after once more forcing a downgrade to py-rattler <0.22 and doing mamba update conda-smithy separately), mamba not only wants to install the broken combination again, but wants it to the point of downgrading smithy
>mamba update --all
conda-forge/noarch Using cache
conda-forge/win-64 Using cache
Pinned packages:
- python=3.12
Transaction
Prefix: E:\miniforge\envs\builder
No specs added or removed.
Package Version Build Channel Size
---------------------------------------------------------------------
Upgrade:
---------------------------------------------------------------------
- py-rattler 0.21.0 py310hb39080a_0 conda-forge Cached
+ py-rattler 0.22.0 py310hb39080a_0 conda-forge Cached
Downgrade:
---------------------------------------------------------------------
- conda-smithy 3.54.2 win_pyhf1ceabd_1 conda-forge Cached
+ conda-smithy 3.54.1 win_pyhf1ceabd_0 conda-forge Cached
Summary:
Upgrade: 1 packages
Downgrade: 1 packages
Total download: 0 B
---------------------------------------------------------------------
In other words (AFAICT), the unpatched repodata of conda-smithy-3.54.1-win_pyhf1ceabd_0 has effectively poisoned my local package metadata. The behaviour persists even after conda clean --all and mamba clean --all.
Since the issue-template asked me to, I ran the same test for conda, i.e. conda update --all, and it considers the environment up to date.
mamba info / micromamba info
libmamba version : 2.5.0
mamba version : 2.5.0
curl version : libcurl/8.18.0 Schannel zlib/1.3.1 libssh2/1.11.1 WinLDAP
libarchive version : libarchive 3.8.5 zlib/1.3.1 liblzma/5.8.2 bz2lib/1.0.8 liblz4/1.10.0 libzstd/1.5.7 libxml2/2.d
envs directories : E:\miniforge\envs
package cache : E:\miniforge\pkgs
C:\Users\[...]\.mamba\pkgs
C:\Users\[...]\AppData\Roaming\.mamba\pkgs
environment : builder (active)
env location : E:\miniforge\envs\builder
user config files : C:\Users\[...]\.mambarc
populated config files : E:\miniforge\envs\builder\condarc.d\anaconda-auth.yml
C:\Users\[...]\.condarc
E:\miniforge\.condarc
virtual packages : __win=10.0.26100=0
__archspec=1=x86_64_v3
channels : https://conda.anaconda.org/conda-forge/noarch
https://conda.anaconda.org/conda-forge/win-64
base environment : E:\miniforge
platform : win-64