Package submitter feedback

Please share feedback and questions about the package submission process in this thread!

1 Like

@Caroline can I submit the logo of my project instead of an AI-generated image? Currently if I read the instruction correctly only an AI generated image using a specific prompt would be accepted to use as the package image on the website

1 Like

Hey @a2svior, yes, feel free to submit it – do you mind labeling it logo.jpeg instead? I’ll update the guidelines shortly.

Oh nice perfect, will do thanks

1 Like

Some feedback while reading the google doc: It’s good practice when publishing packages to do it automatically, in the CI of the repository where the code source is located. Could Modular provide a dummy “hello-world” repository where there are the correct Github action yaml files, so that when creating a release on Github, a release is automatically done with Magic? Here is an example of one of my Python project that does this: python-on-whales/.github/workflows/python-publish.yml at master · gabrieldemarmiesse/python-on-whales · GitHub

I would love to see the equivalent in Mojo.

2 Likes

Second question, how does it works to publish a new version of an existing package? Should I re-do a pull request to update the recipe.yaml and move the README.md and test files in the Modular community channel repository again? Is there a way to automate this process from the source code repository, similar to how it’s possible to publish to Pypi with just a “uv publish” command?

1 Like

Third question, I can’t find the right directory structure for the repository of my package to have unit tests in one directory and the source code in the other. Vscode doesn’t seem to understand that the package is at the root of my directory. When using the command line, I’m forced to use the “-I ./” argument, which can’t be set in vscode for “mojo test” as far as I know. Is there an undocumented trick I’m not seeing? If you want to reproduce, the repository is GitHub - gabrieldemarmiesse/mojo-simdjson: A port of simdjson in Mojo and I want to run the tests with “mojo test ./tests”, but I have to use “mojo test -I ./ ./tests” to run the tests to avoid import errors. Obviously vscode is not aware of this and thus can’t understand my imports.

1 Like

Hey @gabrieldemarmiesse, thanks for all the feedback! Starting with the first question, we wouldn’t be able to automate contributing to one central community channel through individual repos that are owned by community members, primarily because we’d have to give each package owner an API key to upload their package to the community channel, which won’t be scalable. The best way to automate this process would be to create an automation that opens a PR on the modular-community repo to update your rattler-build script when you have a new release. This is definitely doable and we can try to put together an example at some point.

For your second question, yes, the way to update your package would be to submit a pull request to the modular-community repo with the updated recipe, updated README (if it has changed), and updated tests (if they have changed). There isn’t a way to publish automatically from your own repo because it’s one central channel that many people will hopefully contribute to, so we won’t be able to give everyone permissions to upload packages to the channel. That said, it’s definitely doable to create an automation that would open the PR on the modular-community repo in response to a new release from your project’s repo.

Let me do some digging on the third question and I’ll get back to you.

2 Likes

Thank you! I’m definitely looking forward to more automation and de-duplication (I don’t want to maintain my files in two different repos)! uv publish (python) and cargo publish (rust) are for me the “gold standards” in terms of publishing packages. They’re very easy commands, user friendly, and the feedback is really fast in terms of build errors. It could be a north star of mojo packaging.

1 Like

I definitely hear that and it makes a lot of sense. Do you find that you have substantial changes to tests and the README with each new version? That’s a helpful data point as we continue iterating on this system

I’ve been maintaining GitHub - gabrieldemarmiesse/python-on-whales: An awesome Python wrapper for an awesome Docker CLI! for a long time, and in most updates, the readme has changed as well as many unit tests. If I were to seriously maintain a Mojo package with the workflow given in the google doc, I would have to copy the test directory as well as the README every time, regardless of the changes made, just to make sure that they don’t get out of sync with the original repo due to a human error.

This part can be automated as well. In general I prefer automated solutions to avoid human errors.

I have another question regarding releasing a package. Let’s say that I want to make a release every day for users who want a bleeding edge version of my library, similar to Tensorflow nightly or Pytorch nightly. How can I achieve this? If I manage to automate everything on my side of things and submit the PR automatically from the CI every day, wouldn’t that put a very big burden on the reviewers of the Modular community channel repository?

2 Likes

That’s super helpful to know - thanks for sharing. I think creating an example automation for this workflow will be helpful.

Re: your second question, it’s a great point – I think we can potentially designate folks like yourselves who have been pillars of the community for a long time as trusted contributors, so that there isn’t an extensive review process needed when you’re submitting a PR (or perhaps we can give this group elevated permissions).

Just submitted my package, ExtraMojo: feat: add ExtraMojo by sstadick · Pull Request #40 · modular/modular-community · GitHub

The process isn’t bad. I think it’s awkward that I had to copy my tests out of my project and into this one. Presumably the project is getting cloned behind the scenes, can’t a “run tests” command be given similar to the build command?

Questions:

  • Will the project auto-update the way other conda projects do things? Or do I need to manually bump versions and submit a PR each time?
  • Is this the final form of package management? I was hoping for something more like Crates than conda.
  • The Google Doc I followed mentioned t-shirts? :slight_smile:
3 Likes

Hey @duck_tape, apologies for the delayed response and thank you for sharing this feedback!

I reached out via DM re: your swag, and we’re actually working on revising the guidelines to allow you to keep your test files in your package’s repo.

Re: auto-updates – at the moment, this doesn’t happen automatically, but this is definitely something on our radar, since we know it can be a pain to have to open a PR every time you update your package.

We’re still early days in terms of package management, so we appreciate any and all feedback!

1 Like

Hey group, I wanted to inquire about package submissions. For CodeQL tooling there doesn’t look like there is support for Mojo. Are there other recommended alternatives. And um I want the Eagles to win the Super Bowl today

Ideally, we can design most libraries to not need CodeQL or similar tools, since they can be safe by construction. It’s going to be a long time before security vendors pick up Mojo, since they are likely busy improving C++ support and working on Rust.

We don’t require the CodeQL scanning on packages that use only Mojo. If your package uses Python or another programming language in addition to Mojo, we ask that you turn on CodeQL scanning.

1 Like