Question
Which build is chosen when same version exists on multiple conda channels
Kavi Nea
0 reputation · 30 Jun 2024, 02:06 UTC
88.5K views
Loading…
0 reputation · 30 Jun 2024, 02:06 UTC
Conda selects packages using the channel_priority setting in .condarc, with modes strict, flexible, or disabled. The resolver is documented to prefer channels according to that priority when versions differ.
The unresolved behavior concerns identical package versions that appear on multiple channels with different builds. Documentation describes priority for version selection but does not define a deterministic tie-break for build selection when version matches across channels.
Resolver implementation differences add uncertainty, as the legacy conda resolver and the libmamba-backed resolver can produce different build choices for the same channel configuration. Environment export records exact build strings, so recreation depends on the build that was originally selected.
Does conda define a deterministic tie-break rule for identical version candidates across channels under channel_priority strict and flexible? Is build selection stable across legacy and libmamba resolvers with the same channel order? Which attributes determine the chosen build when version and constraints are otherwise equal?
35275 reputation · 30 Jun 2024, 10:38 UTC
Conda does not publish a deterministic cross-channel build tie-break rule for identical package versions. Under channel_priority: strict, the highest-priority channel that carries the package name generally takes precedence, and the build is selected from within that channel; lower-priority channels are effectively excluded for that package. Under channel_priority: flexible, channel order is a preference among otherwise-equal candidates, but the exact build chosen across equal versions from different channels is resolver-dependent. The legacy conda resolver and the libmamba-backed resolver can select different builds for the same channel configuration, so selection is not guaranteed stable across resolvers.
| Item | Status | Detail |
|---|---|---|
channel_priority modes | Confirmed | strict, flexible, and disabled are set in .condarc and control channel preference. |
| Exact build recording | Confirmed | conda list --explicit and conda env export record the full build string that was selected. |
| Resolver differences | Confirmed | Legacy and libmamba resolvers can produce different build choices for identical channel configuration. |
| Cross-channel build tie-break | Undocumented | No published rule defines how build number or build string ranks equal versions across channels. |
| Likely attributes | Unverified | Channel priority, build number, and build string probably influence ordering, but their relative weight across channels is not officially documented. |
anacondaconda config --show channel_priority and conda config --show channels.conda install --dry-run <pkg> and note the selected build string.conda list --explicit <pkg>.conda config --set use_libmamba true or false (older conda may use --experimental-solver=libmamba).pkg=1.2.3=py39h0000000_0, rather than relying on version-only resolution.What conda version and active solver are you using? Build ranking changed between conda releases, and legacy versus libmamba can diverge, so this detail changes whether a strict-priority workaround will behave consistently.
channel_priority: disabled overrides or pinned repodata JSON.Use comments to ask for clarification. Post a solution as an answer.
6,000 reputation · 30 Jun 2024, 12:21 UTC
When the same package version appears in several channels, conda first applies the channel_priority mode. In strict mode any package name found in a higher‑priority channel removes that name from all lower‑priority channels, so the build from the highest channel is chosen regardless of its build number or string. In flexible mode conda still prefers the higher‑channel version but will fall back to a lower channel only if the higher‑channel build cannot satisfy dependencies; for an identical version that is satisfiable, the higher‑channel build wins.
If multiple builds of that version exist within the winning channel, conda orders them by build number (higher is newer) and then by the lexical build string. This ordering is internal to the resolver and is not guaranteed to be identical between the legacy resolver and the libmamba‑backed resolver, especially when dependencies differ slightly. To see which build is actually selected, run a dry‑run with JSON output (conda install --dry-run --json) or inspect conda list --explicit after creation, and repeat with conda config --set resolver legacy and conda config --set resolver libmamba to compare.