Conda channel_priority strict lacks documented tie-breaking for packages present in both defaults and conda-forge
0 reputation · 13 Sept 2025, 03:37 UTC
0 reputation · 13 Sept 2025, 03:37 UTC
Conda's channel_priority: strict setting in .condarc is documented to require all packages to originate from the highest-priority channel that provides them. When an environment.yml lists both defaults and conda-forge, and a package version exists in both channels with different build strings, the documentation does not specify whether strict priority mandates accepting the lower build string from the higher-priority channel or whether a higher build string in a lower-priority channel may be selected.
This ambiguity affects reproducibility because the classic solver and the libmamba solver—now the default in recent conda releases—may apply different heuristics during resolution. The defaults channel is also subject to Anaconda's Terms of Service, which can constrain organizational use, while mixing channels without explicit pins risks ABI incompatibilities in compiled scientific packages. Inspecting the channel and url fields in the environment's conda-meta JSON files reveals which channel supplied each package, but without a documented tie-breaking rule the observed selection remains empirical rather than guaranteed.
Which documented constraint governs build-string selection under channel_priority: strict when the same package version appears in both channels? Does the behavior differ between the classic and libmamba solvers in conda 23.x and later? What is the recommended configuration to make this selection explicit and reproducible?
32775 reputation · 13 Sept 2025, 07:25 UTC
Under channel_priority: strict, the governing constraint is the channel order. Conda will select the package from the highest-priority channel that provides the requested version, regardless of the build string. Build strings are only used as tie-breakers when multiple builds of the same version exist within the same channel.
If defaults is listed above conda-forge in your configuration, Conda will install the build from defaults even if a newer or higher-numbered build string exists in conda-forge.
In Conda 23.x and later, both the classic solver and the libmamba solver (now the default) adhere to this strict priority rule. While earlier iterations of libmamba occasionally exhibited different heuristics regarding build strings across channels, recent releases have aligned libmamba with the classic solver's behavior to ensure consistency.
To eliminate ambiguity and ensure the same build string is selected across different environments or solvers, use the following methods:
environment.yml file for critical packages: dependencies:
- conda-forge::openssl=3.0.8--override-channels flag during environment creation to ignore global .condarc settings and rely solely on the provided list: conda env create -f environment.yml --override-channels -c defaults -c conda-forgeconda list --explicit > spec-file.txt This records the exact URL and build string of every package.You can verify the source of an installed package by checking the conda-meta directory of the environment:
# Check the channel and build of a specific package
cat /path/to/env/conda-meta/package_name.json | grep -E "channel|build"
Diagnostic Note: Please confirm your exact Conda version (conda --version). If you are using a version prior to 23.x, the libmamba solver may not yet be fully aligned with the classic solver's strict priority implementation.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.