mojo-bin: init at 1.0.0 - #559250
mojo-bin: init at 1.0.0#559250
Conversation
nixpkgs-ci
Bot
added
8.has: package (new)
|
cc @Awayfaring |
nixpkgs-ci
Bot
added
the
9.needs: reviewer
d2ecb0f to
0934801
Compare
nixpkgs-ci
Bot
removed
the
9.needs: reviewer
nixpkgs-ci
Bot
added
the
9.needs: reviewer
0934801 to
3f83d17
Compare
nixpkgs-ci
Bot
removed
the
9.needs: reviewer
|
3f83d17 to
87f4bf8
Compare
zinzilulo
left a comment
zinzilulo
left a comment
There was a problem hiding this comment.
Thank you so much for packaging this! With a few small tweaks, this derivation should also work on aarch64-darwin. If we could include Darwin support in the initial release, that would be very convenient.
|
@zinzilulo I do not run aarch64-darwin and so I cannot maintain it, but if you would like to maintain aarch64-darwin for this package I would welcome that. If you want to go that route I propose that you add aarch64-darwin in a follow-up PR in the interest of keeping PRs small and bc I can't develop/test it. |
My hope was to include aarch64-darwin support in the initial PR so that it could merge as a complete change and avoid an additional review cycle. The changes needed for Darwin are relatively small and mostly limited to names and platform strings rather than Darwin-specific details. I’ve also already tested the resulting artifacts and functionality on Darwin. That said, I agree that splitting it into a follow-up PR would make the scope of this PR more manageable. As for the current state of the PR, I’ve built the tests on aarch64-linux and tested both the compiler and REPL, so the packaging itself should be good to go. |
|
ok if you've already tested this, that's fine by me. i applied all suggestions |
zinzilulo
left a comment
zinzilulo
left a comment
There was a problem hiding this comment.
Thanks for the changes. I noticed a mistake in the previous patch, and the lock file didn’t include aarch64-darwin. Fixing these issues should get the CI to green.
nixpkgs-ci
Bot
added
10.rebuild-darwin: 1-10
|
i'll proceed to merge tomorrow unless anyone objects? |
Can you squash all commits to one or just the latest two to |
GaetanLepage
left a comment
GaetanLepage
left a comment
There was a problem hiding this comment.
LGTM, please squash the commits
nixpkgs-ci
Bot
added
the
12.approvals: 1
Package Modular's official stable Mojo 1.0.0 release from fixed-output PyPI wheels under the mojo-bin attribute, while preserving upstream's mojo executable and wheel names. This complements the source-built, CPU-only mojo package with the released binary toolchain and accelerator support. Install the compiler, standard library, LLDB integration, formatter, and the minimal MAX core and Mojo libraries needed for accelerator compilation into one wheel-compatible prefix. Patch bundled Linux ELF objects and add the NixOS driver-link RUNPATH so CUDA can be discovered without relying on LD_LIBRARY_PATH; keep platform-specific patching and LLDB library naming compatible with Apple Silicon Darwin. Keep optional distributed transports out of scope: omit MAX SHMEM, which is not published for aarch64-linux, and remove NIXL's UCX, libfabric, RDMA, and ROCm transport plugins while retaining the core library required by libmax. Mark the package unfree with native-code and bytecode provenance. Support the official x86_64-linux, aarch64-linux, and aarch64-darwin wheels, documenting the Linux x86-64-v3 and Neoverse N1 CPU floors. Include an updater that keeps platform-specific wheels and synchronized Mojo/MAX dependencies pinned, plus passthru coverage for version reporting, interpreted and compiled code, CUDA code generation, driver RUNPATHs, no-GPU behavior, debugger/LSP tooling, and formatting. As an unusual one-off validation, the packaged Linux payload was exercised on an RTX 4090 with driver 595.71.05. It detected nvidia:sm_89 and ran a one-thread kernel with output 0 while LD_LIBRARY_PATH was unset, confirming NixOS driver-link semantics. Co-authored-by: Ken Lin <214774502+zinzilulo@users.noreply.github.com> Assisted-by: Pi coding agent (OpenAI gpt-5.6-sol)
3b6314f to
4901f45
Compare
4 participants
Package Modular's official stable Mojo 1.0.0 release as
mojo-bin(the executable remainsmojo) from fixed-output PyPI wheels forx86_64-linuxandaarch64-linux.Note that unlike #557600, this derivation is conservatively unfree and contains upstream binary/bytecode artifacts, but provides the released toolchain, both published Linux architectures, and CUDA/MAX functionality. The source-built proposal is free, x86_64-only, tracks a post-release snapshot, but does not have GPU/MAX support. I wasn't aware of #557600 when starting this.
Would be worth having some discussion as to which direction we want to go. Assuming GPU/MAX support could be added to the source build I think that would be the clear winner.Done, decided to keep separate mojo and mojo-bin packages. See #557600 (comment).The package combines Mojo's compiler, standard library, LLDB/LSP tooling, formatter, and the minimal MAX runtime required for accelerator compilation. Optional distributed MAX SHMEM and NIXL transport plugins are not included for now.
Homepage: https://www.modular.com/mojo
Validation included:
x86_64-linux.mojo-bin, GPU/MAX support was tested on an RTX 4090 with NVIDIA driver 595.71.05: the exact package output detectednvidia:sm_89and executed a Mojo GPU kernel with output0whileLD_LIBRARY_PATHwas unset.The package is marked unfree and records both native-code and bytecode source provenance.
Things done
passthru.tests.nixpkgs-reviewon this PR. See nixpkgs-review usage../result/bin/.