Conda channel priority build tie-break ambiguity

Which build is chosen when same version exists on multiple conda channels

0 reputation · 30 Jun 2024, 02:06 UTC

88.5K views0

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?

Keep exploring this topic

Conda channel_priority strict lacks documented tie-breaking for packages present in both defaults and conda-forge

Conda's channel_priority: strict setting leaves build-string selection undefined when the same package version exists in both defaults and conda-forge, creating reproducibility gaps between classic and libmamba solvers.

Conda 23.1 libmamba default solver transition breaking cross-environment reproducibility

Conda 23.1 switched the default solver to libmamba, changing resolution semantics. Local dev often uses the classic solver while production uses libmamba, causing environment drift. How to enforce solver parity and lock‑file compatibility across all deployment stages?

Conda environment.yml exports lack explicit build-string pinning for cross-platform reproducibility

Conda environment exports omit build-string identifiers, raising questions about cross-platform binary reproducibility and whether current tooling supports strict build-level pinning without per-platform lock files.

Local macOS Conda Environment vs Linux Production Container: Package Version Divergence

Ensuring that a conda environment defined on macOS produces the same package set in a Linux production container remains challenging due to platform-specific builds and dependency resolution differences.

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.

Which build is chosen when same version exists on multiple conda channels

0 answers

Your perspective belongs here.

1 question comment

Good answers start here.