local multichannel for libmamba v2

[jaimergp]

In #3055 we identified a difference in how conda and mamba populate the local multichannel. @isuruf addressed this for conda-libmamba-solver via #3056 with a new context.conda_build_local_paths attribute that was released in 1.5.6.

This attribute is not present in v2 yet, but @mbargull was pointing out that with v2 we could finally standardize this behavior across implementations and drop the mamba 1.x (accidental?) departures.

If that's not desired, we'd still need the context.conda_build_local_paths bit in v2 though.

[AntoinePrv]

@jaimergp in V2 you'll have the option to not take Mamba's definition of local and define it yourself.

• the specs::Channel class has no hardcoded names,
• the ChannelContext is optional for creating channels, and mostly a holder and sugar for all the parameters needed to create a channel

[AntoinePrv]

Ok, so I'm realizing you rely on the Pool, which needs the ChannelContext. So what you'll want to do is create a ChannelContext and passing it your own parameters with your own definition of local (and then defaults) in the custom_multichannel field. The whole process might be a bit verbose, but you'll end up with full customization.

[jaimergp]

I just need to do it before .make_conda_compatible(), right? According to this, at least:

mamba/libmamba/src/core/channel_context.cpp

Line 147 in 425aef9

// This will not redefine them if the user has already defined these keys.

[AntoinePrv]

Ha yes, either:

• define local in Context.custom_multichannel beforecc = ChannelContext.make_conda_compatible() (or ChannelContext.make_simple for that matter)
• or, don't call cc = ChannelContext.make_conda_compatible(), but cc= ChannelContext(...) for constructing a ChannelContext independently from Mamba's Context.

The first one might be the easiest to do, but the second will be more future proof as we aim to provide a solver API that does not rely on the context.

[jaimergp]

I went with the first option for now, and seems to be working. Thanks for the info! I guess we'll switch to a proper ChannelContext() definition when time comes :D

[AntoinePrv]

ChannelContext is pretty straightforward now (hope its stays that way). Just that you need to use a Context to use it, so that makes it verbose, but anyways, for now you might also need the Context in other APIs so...