Skip to content

Multichannel support #1327

@jaimergp

Description

@jaimergp

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 from repo.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 in condarc.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions