python312Packages.mlx: upgrade and fix build

[Gabriella439]

I polished up the mlx package, both upgrading it and also fixing the build

Things done

• Built on platform(s)
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested basic functionality of all binary files (usually in ./result/bin/)
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[doronbehar]

I don't understand the nature of all the changes, but they don't look bad. Only the separation to different commits is very wrong.

[Gabriella439]

Also, just to clarify: do you want me to merge these as separate commits or is that just for review purposes? Typically I use squash merging, which is why I'm asking

[doronbehar]

OK now that the commit order is better (but still not ideal), I understand the purpose of the PR better. As for the Git commit log, I'd do it like this:

prrte: enable on Darwin
openmpi: Build with prrte by default, for all platforms
python312Packages.mlx: add abriella439 as maintainer
python312Packages.mlx: 0.18.0 -> 0.21.1; unbreak

Note how:

• The packages changed start from the bottom of the dependency tree upwards.
• Each commit prefix starts with a package attribute that is directly handled by Hydra and therefor trigger a build by ofborg thanks to the behavior defined here. Specifically, note the difference between python3Packages and python312Packages. The former is an alias to the later, and Hydra and ofborg really build only the later.
• A package version update like this (to mlx), by nature requires many changes to the expression, and hence there is no point in separating to different commits changes to the mlx expression other then the meta.maintainers change. Especially when the package was broken before this PR.

As for the openmpi debate around the prrte change: I'm glad you have discovered that prrte builds fine on Darwin and that openmpi builds fine with it too. I'm also not sure why mlx won't build for you with openmpi compiled with the internal prrte - it'd be interesting to investigate but I don't think it is important enough, because either way, we don't necessarily have to settle this debate, if we'd simply use in openmpi/package.nix:

lib.withFeatureAs true "prrte" (lib.getBin prrte)

Also, I expect the --without-prrte flag to be unsupported by openmpi's ./configure script, just like --without-ofi-libdir which is mentined there as well.

In general, Nixpkgs favors using our builds of dependencies instead of upstream vendored versions of such dependencies, as it can potentially save disk usage. That's another reason to enable prrte unconditionally / use our version of prrte unconditionally.

[doronbehar]

Changes look great, including the commit messages are very well undestood. Thanks for the contribution! I'll give @markuskowa a day or two to approve / merge.

[doronbehar]

I once heard someone saying that platforms.unix includes BSD, which is not necessarily a supported platform :). However, for most practical purposes, this is the same, as Hydra doesn't build for BSD ;). Just noting it here for you so you'd know for next time. Don't worry this is not a blocker for the PR.

[markuskowa]

Thanks! LGTM.

Side note: When I package new packages (such as PRRTE), I only enable them for Linux usually. Darwin support is difficult to handle if you do not have access to a Darwin machine. I thus leave it to Darwin user/devs to enable Darwin support on packages.