mamba-org
packages using channel::package syntax are always reinstalled
With micromamba v0.22.0 it appears that specifying the channel of a package forces it to be reinstalled.
MWE:
micromamba create -n test -y numba::numba -c conda-forge
micromamba install -n test -y numba::numba -c conda-forge
The second command produces this output:
__
__ ______ ___ ____ _____ ___ / /_ ____ _
/ / / / __ `__ \/ __ `/ __ `__ \/ __ \/ __ `/
/ /_/ / / / / / / /_/ / / / / / / /_/ / /_/ /
/ .___/_/ /_/ /_/\__,_/_/ /_/ /_/_.___/\__,_/
/_/
conda-forge/win-64 Using cache
conda-forge/noarch Using cache
numba/noarch No change
numba/win-64 No change
Pinned packages:
- python 3.10.*
Transaction
Prefix: [redacted]\envs\test
Updating specs:
- numba::numba
Package Version Build Channel Size
---------------------------------------------------------------------------
Reinstall:
---------------------------------------------------------------------------
o numba 0.55.1 np1.21py3.10hd3205ba_g76720bf88_0 numba Cached
Summary:
Reinstall: 0 packages
Total download: 0 B
---------------------------------------------------------------------------
Transaction starting
Changing numba-0.55.1-np1.21py3.10hd3205ba_g76720bf88_0 ==> numba-0.55.1-np1.21py3.10hd3205ba_g76720bf88_0
Transaction finished
Replacing numba::numba with just numba and the reinstallation does not occur.
Not strictly a bug, since the end result is the same, but it does slow it down somewhat (particularly if you do pytorch::pytorch instead).
I'm seeing this and finding it fairly annoying.
mamba --version
mamba 1.0.0
conda 22.9.0
Still present with:
mamba 1.4.0
conda 23.1.0
This causes a fair amount of unnecessary churn when updating our environments.
I don't know anything about how mamba works. If I did, I'd be happy to - but I have no idea where to start.
To be honest I think this will be relatively hard to debug. If you are familiar with C++ debugging maybe you can backtrack from where the update message is printed to where the decision is made to update this particular package. Maybe setting the log level to the highest level can be helpful as well.
I've attached a trace. mamba-trace.log
The most relevant seems to be:
info libsolv solving...
info libsolv resolving job rules
info libsolv prune_to_best_version_conda 9
info libsolv - numba-0.56.3-np1.21py3.10ha54aa7d_g6982acdaa_0 [1022677]
info libsolv - numba-0.56.2-np1.21py3.10ha54aa7d_gd6731f6d2_0 [1022685]
info libsolv - numba-0.56.0-np1.21py3.10ha54aa7d_gf75c45a8d_0 [1023536]
info libsolv - numba-0.56.0rc1-np1.21py3.10ha54aa7d_gea8407264_0 [1023914]
info libsolv - numba-0.55.0rc1-np1.21py3.10ha54aa7d_gf2a673cd0_0 [1024090]
info libsolv - numba-0.55.1-np1.21py3.10ha54aa7d_g76720bf88_0 [1024331]
info libsolv - numba-0.56.4-np1.21py3.10ha54aa7d_g288a38bbd_0 [1025024]
info libsolv - numba-0.55.0-np1.21py3.10ha54aa7d_gd44b8f446_0 [1025178]
info libsolv - numba-0.55.2-np1.21py3.10ha54aa7d_g2298ad618_0 [1025419]
info libsolv installing numba-0.56.4-np1.21py3.10ha54aa7d_g288a38bbd_0
info libsolv resolving installed packages
info libsolv prune_to_best_version_conda 36
info libsolv - ca-certificates-2022.12.7-ha878542_0 [10]I
info libsolv - ca-certificates-2016.2.28-0 [378984]
info libsolv - ca-certificates-2016.8.2-3 [378985]
info libsolv - ca-certificates-2016.8.31-0 [378986]
info libsolv - ca-certificates-2016.8.8-0 [378987]
info libsolv - ca-certificates-2016.9.26-0 [378988]
info libsolv - ca-certificates-2017.1.23-0 [378989]
info libsolv - ca-certificates-2017.1.23-1 [378990]
info libsolv - ca-certificates-2017.11.5-0 [378991]
info libsolv - ca-certificates-2017.4.17-0 [378992]
info libsolv - ca-certificates-2017.7.27.1-0 [378993]
info libsolv - ca-certificates-2018.1.18-0 [378994]
info libsolv - ca-certificates-2018.10.15-ha4d7672_0 [378995]
info libsolv - ca-certificates-2018.11.29-ha4d7672_0 [378996]
info libsolv - ca-certificates-2018.4.16-0 [378997]
info libsolv - ca-certificates-2018.8.13-ha4d7672_0 [378998]
info libsolv - ca-certificates-2018.8.24-ha4d7672_0 [378999]
info libsolv - ca-certificates-2019.11.28-hecc5488_0 [379000]
info libsolv - ca-certificates-2019.3.9-hecc5488_0 [379001]
info libsolv - ca-certificates-2019.6.16-hecc5488_0 [379002]
info libsolv - ca-certificates-2019.9.11-hecc5488_0 [379003]
info libsolv - ca-certificates-2020.11.8-ha878542_0 [379004]
info libsolv - ca-certificates-2020.12.5-ha878542_0 [379005]
info libsolv - ca-certificates-2020.4.5.1-hecc5488_0 [379006]
info libsolv - ca-certificates-2020.4.5.2-hecda079_0 [379007]
info libsolv - ca-certificates-2020.6.20-hecda079_0 [379008]
info libsolv - ca-certificates-2021.10.8-ha878542_0 [379009]
info libsolv - ca-certificates-2021.5.30-ha878542_0 [379010]
info libsolv - ca-certificates-2022.5.18-ha878542_0 [379011]
info libsolv - ca-certificates-2022.5.18.1-ha878542_0 [379012]
info libsolv - ca-certificates-2022.6.15-ha878542_0 [379013]
info libsolv - ca-certificates-2022.6.15.1-ha878542_0 [379014]
info libsolv - ca-certificates-2022.6.15.2-ha878542_0 [379015]
info libsolv - ca-certificates-2022.9.14-ha878542_0 [379016]
info libsolv - ca-certificates-2022.9.24-ha878542_0 [379017]
info libsolv - ca-certificates-2022.12.7-ha878542_0 [670183]
info libsolv Fallback to timestamp comparison: 0 vs 1670457595: [1]
info libsolv Selecting variant [b] of (a) ca-certificates-2022.12.7-ha878542_0 vs (b) ca-certificates-2022.12.7-ha878542_0 (score: 1)
info libsolv creating a branch [data=5564327]:
info libsolv - ca-certificates-2022.12.7-ha878542_0
info libsolv - ca-certificates-2022.12.7-ha878542_0
info libsolv installing ca-certificates-2022.12.7-ha878542_0
and
info libmamba Problem count: 0
info libsolv ordering transaction
info libsolv transaction elements: 1
What's interesting is that we see both installing ca-certificates-2022.12.7-ha878542_0 and installing numba-0.56.4-np1.21py3.10ha54aa7d_g288a38bbd_0, but only the latter ends up getting added to the transaction. I'm guessing there is some check of the "installing" elements to see if they are already present in the environment, and for some reason that check is failing with the channeled package.
I can't sort out the program flow. It seems like at some point the fact that numba::numba is already installed isn't getting recognized and so not being removed from the transaction. But being completely unfamiliar with the code, I'm at a loss.
Yes, unfortunately the code base is very complicated. Maybe it helps to compare what happens when you leave out the channel specification (in which case things should work correctly) and compare where the program shows different behavior.
I did, but there just isn't much to go on. The only real notable difference is that the transaction elements changes:
info libmamba Problem count: 0
info libsolv ordering transaction
info libsolv transaction elements: 0
Hmm, another diff: Reinstall/channel specific:
info libsolv allowuninstall=0, allowdowngrade=1, allownamechange=1, allowarchchange=0, allowvendorchange=0
no-reinstall:
info libsolv allowuninstall=1, allowdowngrade=0, allownamechange=1, allowarchchange=0, allowvendorchange=0
Although I'm not sure this matters as we don't see either an uninstall or a downgrade.
Channel specific jobs do appear to be handled differently by https://github.com/mamba-org/mamba/blob/05f1b9b6b3ba4fc7cdb23b9fdf7d23ebaac1461a/libmamba/src/core/solver.cpp#L252 - but again, I can't really parse this code.
I'm not seeing that difference in the logs when I try this:
micromamba install zlib
micromamba install conda-forge::zlib
But what's interesting is that there is this difference:
info libsolv job: install providing zlib # zlib
info libsolv job: install unknown job select # conda-forge::zlib
Also, for zlib there is this in the logs:
info libmamba Adding job: zlib
[...]
info libsolv zlib-1.2.13-h03a7124_4 [193373]I
whereas for conda-forge::zlib both are missing.
I think this might actually be a bug in libsolv. My hypothesis is that it is falsely reporting MAMBA_FORCE_REINSTALL=1
Or maybe that's wrong and it always calls add_reinstall_job and the problem is somewhere in this code https://github.com/mamba-org/mamba/blob/05f1b9b6b3ba4fc7cdb23b9fdf7d23ebaac1461a/libmamba/src/core/solver.cpp#L301-L338
Still seeing this with micromamba 1.5.3. This may be the one last annoyance for me with mamba - any more ideas on how to fix this?