-
Notifications
You must be signed in to change notification settings - Fork 34
Description
Checklist
- I added a descriptive title
- I searched open requests and couldn't find a duplicate
What is the idea?
Currently, when Conda installs a package, if that package is found in a channel, the solver also considers that channel for all dependency resolution.
The idea is to allow restricting a channel so that it can be used only for the explicitly requested package, and not for its dependencies.
Desired state: A user can specify a channel for a package (e.g., -c testing), but Conda will continue resolving dependencies only from other configured channels (such as defaults or conda-forge) unless explicitly instructed otherwise.
Why is this needed?
This would benefit developers and teams who:
• Maintain testing or experimental channels.
• Want to try a package from such a channel without pulling in unstable or unintended dependencies.
• Need strict reproducibility and isolation in multi-channel workflows.
It solves the current problem where uploading one package to a custom channel exposes all other packages in that channel to the solver, leading to potential conflicts or unwanted dependency versions.
What should happen?
From a user perspective:
# Existing behavior today
conda install conda-forge::mypkg
# → mypkg is taken from conda-forge, dependencies may also be pulled from conda-forge
# Proposed new behavior
conda install testing:::mypkg
# → mypkg is taken from testing channel
# → dependencies are resolved only from defaults/conda-forge (unless explicitly specified)
-
If a dependency exists only in the restricted channel, Conda should fail with a clear error message and instruct the user how to proceed (e.g., use testing::depX explicitly or allow the channel).
-
Multiple restricted packages could be combined:
conda install testing:::pkgA staging:::pkgB
Neither channel would be used for other dependencies.
Possible implementation approaches:
• New channel:::pkg spec syntax (extension of the current channel::pkg format).
• CLI flag: --channel-package-only testing.
• Config option in .condarc (e.g., channel_restrictions: { testing: package-only }).
Additional Context
- Current workarounds (dedicated channel per package, manual pinning in meta.yaml) are inefficient and hard to maintain.
- channel_priority: strict and --override-channels don’t cover this use case, since dependencies are still pulled from the channel.
- The proposed syntax is backward-compatible, ergonomic, and aligns with existing channel::pkg semantics.
- This feature would significantly improve reproducibility and control in environments where experimental or internal channels coexist with stable channels.