RFC: Let workspaces optionally source/override channels from global config (a .condarc-like behavior)

[nachofest]

Pixi currently writes channel lists into the project manifest and treats that list (and order) as the source of truth. I’m proposing an opt-in mechanism for projects to defer channel resolution to global config (with clear precedence rules). My concern is that on complex repo structures (specially within organizations), changes to order, addition of channels etc can yield can be complex. Users typically will inherit from a base image with some global config (just like conda) and use that as the source of truth and rely on SME to have that updated accordingly. If they dont trust it then they should still be free to override with their own configuration - again precedence here.

Current behaviour (what I see in docs)

• pixi init writes channels into [tool.pixi.workspace] (or pixi.toml). That manifest is then used for solves/installs.
• Channel priority/order is taken from the workspace channels array (first = highest).
• Global config.toml supports default-channels, but those are only used at init (and for pixi global install), not to live-override an existing project’s channels.
• Pixi reads config files from multiple locations with defined precedence (system → user → project), highest priority wins.

By contrast, Conda’s .condarc can define channels and their priority globally; projects pick that up at runtime.

The problem this causes

In org/container workflows, we’d like consumers to do:

FROM our/pixi-base:2025.10
RUN pixi install
CMD [...]

…where the base image carries the authoritative channel policy (ordering, internal mirrors, emergency swaps). If we discover a bad order or need to rotate to a new internal channel, we publish :2025.11, and users just bump the tag. Today, because channels are pinned in each repository’s manifest, we have to PR every repo to change the list/order.