fix: update channel ordering to reflect priority

[sstadick]

Possible fix for #153, where the wrong regex package is being pulled as a dep for max.

This PR adds default channels to the build script, and puts them in priority order of conda-forge, max, modular-community

A follow up that could be added to check if a recipe name collides with anything in conda-forge or max. Draft of follow up: https://github.com/sstadick/modular-community/pull/1

[Hofer-Julian]

Shouldn't the order be the other way around?

[sstadick]

I think it's correct, unless I'm misunderstanding the priority. My intent is that conda-forge should be the highest priority place to look, followed by max, and then lastly modular-community.

The issue that spawned this was the modular-community regex package preventing the conda-forge regex package from being installed, which is a dependency of max.

[Hofer-Julian]

I understand the issue now that you are trying to solve but I don't think that's a good default. I'd say it's more likely to happen that you want to depend on a dependency in modular-community that also exists in conda-forge than the other way around.

@wolfv what is the best way to enforce that a certain dependency comes from a specific channel with rattler-build?

[sstadick]

If there's a better way, that would be preferable! I just didn't see a way to specify that in a rattler-build file.

[carolinefrasca]

I would also love to learn if there is a better way!

[carolinefrasca]

LGTM and agreed on the priority logic. Let me just give some other folks a heads up and then I'll merge

[Hofer-Julian]

LGTM and agreed on the priority logic. Let me just give some other folks a heads up and then I'll merge

Ah, if it's fine by you, then feel free to merge :)

[carolinefrasca]

@Hofer-Julian If there's a better way to enforce pulling a specific dependency from a specific channel, we'd probably prefer to do that

[Hofer-Julian]

@carolinefrasca I discussed that with @wolfv and we recommend avoiding name conflicts with channels you depend on like max and conda-forge. Specifically, we suggest renaming regex to mojo-regex.

There should be a way to specify channels for specific dependencies in rattler-build, however repo data doesn't support that. This means that transitive dependencies might still be messed up.

[carolinefrasca]

@Hofer-Julian Thank you! That makes sense.

@sstadick I think the best plan of action is to change regex to mojo-regex, as well as make the priority ordering change that you mentioned. Thoughts?

[sstadick]

@carolinefrasca - I think regex was already changed to mojo-regex, but since it got published once, it's still out there for the solver to find: https://prefix.dev/channels/modular-community/packages/regex do you have permissions to remove that package entirely?

But then yes, I think the re-ordering will help.

We could also add something like this check: https://github.com/sstadick/modular-community/pull/1 which searches same-name packages in conda-forge and max channels before building a mojo package (it needs a rebase and fixup). I don't love how this works and imagine there's a better way, but it would prevent any other accidental collisions.

[carolinefrasca]

Oh yup I believe I can remove it via API - let me try that

[carolinefrasca]

That worked – merged your other PR. I can make the argument for both priority orderings... the most ideal solution is probably just preventing naming collisions in the first place

[sstadick]

Agreed, that follow up PR I posted feels like a rather hacky way to do that via conda search, but maybe it's better than nothing?

[carolinefrasca]

Seems like a good solution for now to me!

[sstadick]

Seems like a good solution for now to me!

I will get it cleaned up then!

[sstadick]

@carolinefrasca, I've cleand up https://github.com/sstadick/modular-community/pull/1, but it's still based on this branch.

Are you wanting to do both things - fix the channel ordering to use conda-forge first, and then also add a package name check, or just the name check?

[carolinefrasca]

@sstadick I think it probably makes sense to do both? I can also add it as a requirement in the checklist for folks to note that their package doesn't have name collisions with an existing conda-forge package.

[sstadick]

@carolinefrasca - merged the name check code into this branch. So now this PR does both.

List of packages with currently conflicting names:

• nanoid
• websockets
• infrared
• mosaic

See output of build-all here: https://github.com/modular/modular-community/actions/runs/16626843765/job/47045522928?pr=157

The conda-search is kind of slow, but not unbearable 🤷

[carolinefrasca]

Thank you so much! websockets should be fine because it was renamed to mojo-websockets (I can go in and delete the old version).

For nanoid, infrared, and mosaic, heads up to @ucirello, @helehex, and @christianbator – it would be awesome if you could update your package names to mojo-nanoid, etc. or something else that doesn't conflict with an existing conda-forge package.

[carolinefrasca]

Before we merge this, let me just reach out to folks individually to give them a heads up on the name changes needed