-
Notifications
You must be signed in to change notification settings - Fork 93
Description
Checklist
- I added a descriptive title
- I searched open requests and couldn't find a duplicate
What is the idea?
Add an optional field in rattler.Channel
that allows users to refer to this channel with another name(s). e.g. the python
package in https://repo.anaconda.com/pkgs/main
can be queried with both pkgs/main::python
and defaults::python
.
The option can be named multichannel_names
, additional_names
, extra_names
, etc.
Why is this needed?
conda
and mamba
have this notion of Multichannel
objects: a channel that is actually composed of a number of channels underneath. It is used to merge existing channels under a unified name in the CLI. I don't like how they are implemented in conda
, but we do need to implement that UX use case in the CLI (e.g. requesting a package from defaults
by doing conda install defaults::python
instead of pkgs/main::python
.
Common multichannels are:
- By default, conda has a multichannel named
defaults
, which pulls fromrepo.anaconda.com/pkgs/{main,r,msys2}
. - conda-build injects a multichannel named
local
, which pulls from the all the local paths conda-build puts built artifacts in. - Users can define their own via
custom_multichannels
option incondarc
.
What should happen?
I think the best solution is to add an option in ChannelConfig
. Then the solver bits would need to be aware of these extra names when querying, filtering and sorting the records.
Additional Context
No response