Package submitter feedback

If I ship a Mojo package without the mojoproject.toml file, do the dependencies have to be manually added by an end user?

If my package has to interface with system libraries for UI, but I only currently support macOS, for example - is there a way to specify that for a package and then later add support for Linux (and eventually Windows)?

The .mojopkg will be fine of course, but the additional glue code in shared libraries isn’t cross-platform yet.

Hey @christianbator, thanks for sharing this question! We do currently require for the package to build successfully on Mac and Ubuntu - let me check with the team to see if we might be open to relaxing this requirement.

Actually to clarify, the package will build on Mac and Ubuntu just fine, but some features will only be available on Mac for a bit. I can put them behind a feature flag for now, then there’s no need to change the GitHub workflow to only build on Mac. Hope that works, thanks!

I have 2 questions about tests in the recipe @Caroline.

  1. Is there a way I can test the validity of my recipe locally before submitting it? (e.g. that the tests are properly executed etc.)
  2. The recipe mentions individual test files. I have many test files, and I usually invoke tests via mojo test MyTestFolder.
    (a) To specify the correct command / path, in which directory do I expect to be when the test command is called / the test files are thought?
    (b) Do I need to provide the path to my package via the -I option or can I assume the package is installed already?
    (c) Is it sufficient if I provide the path to the test folder in the tests: files: recipe section?
1 Like

I use rattler-build build -c https://conda.modular.com/max -c conda-forge --skip-existing=all -r ./recipe.yaml to test my recipe before pushing.

For your other questions, you can check out how the other recipes build. Here’s one of my packages, for example.

In general, @thatstoasty (github username) seems to have some really nice CI around his projects and his recipes are always up to date. Example for small_time.

2 Likes

Thanks, very helpful (as is the rattler doc, actually)!
Does Mojo community packages only support major Mojo releases or can I also include a dependency currently only found on nightly? Currently my package depends on a fix that has not made it to main…

You can support nightly by changing the mojo version in the recipe, yes, and that is fine! That package just won’t be installable by someone who has their mojoproject pinned to stable, for example.

So, I think it should work? For the most part the packages there specifically pin to the latest stable mojo for now and don’t try to support more than one version (at least that’s what I’ve been doing).

I tried simply including the nightly Mojo version in the max_requirement item, but this failed with ā€œversion not foundā€, specifically

Cannot solve the request because of: No candidates were found for max
      25.3.0.dev2025040705.*.

in my case (see full protocol here).

This also happens locally if I do not adjust the rattler-build command to consider the nightly channel.

rattler-build build -c https://conda.modular.com/max-nightly ...

Is there a different way how I can specify the max channel?

Hey @samufi, I believe that I have to add this to the repo first – let me confirm that it won’t break any of the existing packages and I’ll get back to you later today.

1 Like

Hi @samufi, unfortunately adding this nightly breaks the Mosaic package – let me reach out to the owner and ask them to update their package, and then once that’s done, I can add that nightly to the channel.