It is not recommended. The conda documentation says it is not recommended to mix channels in a single environment, and advises configuring either defaults or conda-forge globally, not both. Mixing can cause incompatible packages and hard to debug conflicts. If you must mix, the docs recommend strict channel priority.
Why channels are a supply chain question
A conda channel is a source of packages. Each channel you add is another party you trust to publish the compiled code that will run in your training job. Order matters too: the same package name can exist in several channels, and the channel that wins decides whose build you get.
For ML work this is acute because compiled libraries such as numerical and GPU packages must agree with each other at the binary level. The docs warn that installing from a channel outside your configuration with the channel double colon package syntax can cause binary and ABI incompatibility errors if the channels are not fully compatible.
How priority works
| Mode | Behavior | Set with |
|---|---|---|
| Default | Prefers a higher priority channel over any version in a lower one, then newest version, then build | Nothing |
| Strict | Excludes lower priority channels when the package name exists in a higher one | Set channel_priority to strict in conda config |
| Disabled | Sorts by version first, so the newest version from any listed channel can win | Set channel_priority to disabled in conda config |
The docs caution that strict priority can make some environments unsatisfiable, so you may need to adjust your package list. They also say strict priority prevents fallback to lower priority channels when a same named package exists in a higher one, which is the property you want for predictability.
Disabled mode deserves care. It lets the newest version from any channel win, so adding a channel can quietly change where core packages come from.
A sensible setup for a team
- Pick one primary channel and put it first in your configuration.
- Avoid adding extra channels just to get one package. Ask whether pip or a source build is a better fit, and note it.
- Commit an environment file listing channels explicitly, so the setup is visible in review.
- Turn on strict priority if more than one channel is configured.
- Export a lock or explicit package list for the environment that trained a model, and store it with the model.
- Review any new channel the way you review a new dependency source.
Mixing conda and pip
Many ML environments install most packages with conda and a few with pip. Install conda packages first and pip packages last, and avoid going back and forth. Pip does not know about conda's solver, so a late conda install can overwrite what pip placed. See pip hash checking for ML environments for the pip side.
What to record
For each trained model, keep the channel list, the priority setting and the exact package versions. That makes an incident review possible later.
Safeguard's dependency scanning and SBOM generation can help inventory what ended up in an environment. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a full list of dependencies makes unfamiliar sources easy to spot.
Quick check
Which channel should I choose?
The docs say to configure one globally. The right one depends on your packages, so test and record your choice.
Does strict priority always work?
No. The docs warn it can make some environments unsatisfiable.
Sources
Last reviewed: 19 October 2026.
