prefix-dev / rattler-build

rattler-build is a universal package builder for Windows, macOS and Linux
https://prefix-dev.github.io/rattler-build
BSD 3-Clause "New" or "Revised" License
187 stars 38 forks source link

Allow to change channel priority #343

Open beenje opened 10 months ago

beenje commented 10 months ago

It looks like channel priority is set to strict mode when testing with rattler-build.

This is an issue for us as we have 2 internal channels: the default one for stable packages and a "dev" one for testing. When building a dev package we pass the "dev" channel and usually want the most recent version of some dependencies to be installed. That could come from the dev or stable channel.

I haven't seen a way to configure the channel priority. It would be great to have a flag or another way to change that.

wolfv commented 9 months ago

Hi @beenje indeed, we need to figure out how to do all of this. Another question is wether channel-specific matchspecs should work (e.g. conda-forge::pytorch).

beenje commented 9 months ago

Another question is wether channel-specific matchspecs should work (e.g. conda-forge::pytorch).

Unfortunately, I don't think that would help with our workflow :-(

chebee7i commented 5 months ago

Any update on this for channel-specific matchspecs?

wolfv commented 5 months ago

No updates yet, sadly.

I think our thoughts are to extend the variant_config.yaml file to include channels and solver mode. For example:

options:
  channels: [...]
  mirrors: ... (or from global configuration)
  channel_priority: strict/lax
  target_platforms: ... ? should probably be a map? do we need this?

compilers:
  cxx: gcc 12.3
  c: co
  linux-64: 
     cxx: bla

variant_configuration:
  boost_cpp:
    - 1.4.5
    - 1.6.5
  bla: ...  
...
AaronOpfer commented 1 month ago

This is a blocker for my work using rattler-build as we have repackaged several third-party packages for compatibility reasons and have inserted them into their own channel, which only works if the solver can pick from our channel or conda-forge without preference. If the compatibility channel is strictly preferred first, then builds on modern versions of Python break, and vice versa.