nix: refactor and clean up flake

[faukah]

Clean up the flake massively. This PR:

• Drops flake-utils
• Drops flakebox
• Uses only nixpkgs to build presenterm
• Uses good practices for writing Nix flakes.

I've put the shell and the package definitions into their own package.nix and shell.nix, feel free to say if this clutters up the repo too much, I can just move them into the flake.nix itself.

Cheers!

[RGBCube]

How does this handle incremental compilation? Without crane, every rebuild builds every single dependency again.

[faukah]

How does this handle incremental compilation?

That's what you have cargo for.

Without crane, every rebuild builds every single dependency again.

This project builds fairly quickly since the amount of deps isn't too large; Adding crane introduces complexity for basically no benefit since no anyone is going to be spamming nix build to build presenterm repedeately.

[RGBCube]

          config = { 
             github.ci.buildOutputs = [ ".#ci.${projectName}" ]; 
           };

Considering that this was a part of the original code, incremental rebuilds are important.

[faukah]

          config = { 
             github.ci.buildOutputs = [ ".#ci.${projectName}" ]; 
           };

Considering that this was a part of the original code, incremental rebuilds are important.

They're not incremental, even with crane, since they're not getting cached.

[mfontanini]

I don't use nix so it's hard for me to chime in here, although I do like many lines removed. Are there any drawbacks to this approach? @dpc you added the initial flake.nix, can you chime in here?

[mfontanini]

Although I have to say, for myself as I don't use nix, what I care about the most is fast PR builds and this seems to add an extra 3ish minutes to the build, see this build vs the latest master run.

[dpc]

This PR switches the flake to produce only one output using rustPlatform.buildRustPackage, which how release version of stuff get built in Nixpkgs & NixOS.

Such a way to build is fine if you only want people to be able to consume the project as end users. But is rather unsuitable for CI, as building a full release profile from scratch is 10x or more slower, and rustPlatform.buildRustPackage has no support for caching the build of dependencies to reuse it between runs.

A simplest way to add deps build caching and building in debug profile is crane. The idea is that list of dependencies changes rarely, and takes longest to build, so it's built as a separate step so it can reuse most of the time.

Flakebox is my wrapper around crane, which makes setting things in CI using crane even easier, adds ability to produce cross-compiled binaries as outputs, support for mold and wild linkers for even faster linking, integrates all of this into Nix dev shells (including xcompilation), includes source filtering so Nix build doesn't need to run e.g. README.md changes, and has support for creating custom CI build profiles optimized even more than usual debug profile for CI needs. I used it because I have a template and slap it on all my own projects. It was built and is maintained to support >100k LoC projects I work at $dayjob (eg. Fedimint), where optimized Rust CI becomes really important.

I guess you might have been running it all without any Nix cache, and since presenterm is relatively small, the dev build was fast enough to not bother you much, but you can get a free 5GB Cachix account with Github login, add the secret to Github Actions settings, and enjoy even faster Nix CI builds.

Now... as for which one to use, it's entirely up to you.

The one from PR is fine, but you will probably want to drop it from your CI.

The Flakebox (current) one has a downside of me being some rando from the webz. Otherwise it's the most optimized, easy to use and feature-rich way to deal with Rust projects with Nix in CI.

A middle-ground would be to switch to bare crane, which is a very popular and well respected project, and lots of stuff that Flakebox improves on top of crane, you probably don't care about.