How can I add set channel_priority flexible in pixi?

[raybellwaves]

In conda I can do conda config --set channel_priority flexible. Curious what that looks like in a pixi.toml file

FYI i'm tinkering with this on google colab: https://colab.research.google.com/drive/1iW3qrKYeZGMrt2735b_LTi9mwNKCGz0L?usp=sharing and trying to install rapids

Came across #615 (comment)

I see I may have to specify the packages by hand. Not ideal but I image there may to ways to i.e.

!conda install --solver=libmamba -c rapidsai -c conda-forge -c nvidia rapids=24.02 python=3.10 cuda-version=12.0

Then get a conda lock then convert to to a pixi.toml file but ideally I would say in pixi end-to-end

[ruben-arts]

Hey @raybellwaves,

I understand the request. We've moved away from the conda-lock format so that will probably not be our preferred way. But I see that this could be a configuration option we could add.

@baszalmstra what do you think of this?

[baszalmstra]

At the moment this is not configurable, I can imagine that we could add something like this to pixi.toml.

But regardless, I would highly recommend against "flexible" channel priority. It will highly increase the risk of mixing packages from different channels which can cause all sorts of very strange behavior at run-/build time and it opens up some nasty supply chain security attacks. Instead, prefer to specify explicitly which package you want to install from which channel. #615 (comment) shows you how to do that.

[dp-alvarez]

Contributing here my use case for this feature as food for thought if you guys go ahead with it:

My company has a internal conda channel with patched versions of upstream libraries. Some projects depend on those custom versions, some depend on the upstream versions.
Without flexible channel priority, we can't get the solver to pass regardless of the channel order as some dependencies may depend on a patched version of a library and other dependencies depend on the upstream version of another library (that is also available as a patched version).
We can work around it by manually finding all the dependencies that should come from our internal channel and set their channel one-by-one, but that doesn't really scale.

I agree with your reservations about implementing this, but I don't see other options for allowing this kind of use case.
Maybe require flexible channel solving to be specified on a per-project, or even per-channel, basis instead of globally would make it less dangerous?