Hey recently got an interest to try out Roc and contributing what I can!
I noticed that the default.nix
is duplicating a fair number of logic from the dev shell in flake.nix
.
Any objections to moving more of the nix logic into the flake and using https://github.com/edolstra/flake-compat to keep the default.nix build working outside of flakes?
Some extra benefits would also be allowing us to use rust-overlay
to pin our rust version from the toolchain toml for the package build and remove the pkgs.lib.assertMsg rustVersionsMatch
in defualt.nix
That all sounds great @John Murray, I've been wanting to do that but could not get around to it. Go for it :)
Awesome! Hopefully will have something up tonight or tomorrow
Pushed up https://github.com/roc-lang/roc/pull/5990. Let me know if I should add any additional comments to the nix setup or write up any documentation on it!
I noted in the pr description that I see one error with cargo test
, the same error seems to happen on main for me so hoping CI will be happy...
Thanks @John Murray :heart:
I'll review later today :)
Another potential nix cleanup I've been thinking about
Right now the nix build for roc has src = pkgs.nix-gitignore.gitignoreSource [ ] <repo_root>
This is pretty inefficaint since any file change checked into to git will cause the derivation to be rebuilt.
This is also possibly why adding a binary cache didnt help much since it basically always needed to do a full rebuild.
Thankfully in the next nix stable release which will be out tomrrow there is a file set api this should make it much easier to filer down that build to just the code needed to build the roc compiler (ie we can ignore all markdown files, webstie files, etc)
If there are no objections would yall be cool with doing that? The only potential issue is we would need to update the nixpkg input in the flake. If that causes pain we could add a new input that has a different version of nix pkgs pinned just pull in that lib
Future improvments can also be using https://github.com/ipetkov/crane which should help cache some of the rust deps + make it easy to run tests from nix
Sounds cool. One thing to note is that new Rust crates get added every so often as the project grows. Ideally the derivation should just discover those automatically, without the author knowing anything about how the Nix build works.
good point @Brian Carroll , my hope is too mostly do very high level filtering
Ie the nix build only looks at the crates
folder, filters out any generated files, and exclude readmes. Hopefully that should make any new crates "just work"
Also probably worth while to filter out the test crates since those are not run in the nix build anyway.
We can revist the tests in nix once we have crane setup
Last updated: Jul 06 2025 at 12:14 UTC