gitoxide icon indicating copy to clipboard operation
gitoxide copied to clipboard

[nix] add a `flake.nix` based on `flakebox`.

Open c4lliope opened this issue 2 months ago • 7 comments

See: https://github.com/rustshop/flakebox/blob/master/docs/building-new-project.md

I opened an issue on their repo concerning a breaking API change, and had the following discussion on Matrix:


today c4lliope joined the room

c4lliope hello - is anyone here? I'm seeing an odd error as I go through the basic guide: https://github.com/rustshop/flakebox/blob/master/docs/building-new-project.md#extra-dependencies

➜ hx flake.nix; nd nix build .#gitoxide
warning: Git tree '/home/calliope/disc/nvme0n1p6/code/gitoxidelabs/gitoxide' is dirty
error:
       … while evaluating the attribute 'devShells'
         at /nix/store/kwpljf3n2xlxlrq5k0p02c6kghc4n6ca-source/flake.nix:56:7:
           55|       packages.default = legacyPackages.gitoxide;
           56|       devShells = flakeboxLib.mkShells {
             |       ^
           57|         packages = [ ];

       … while evaluating the attribute 'lib.x86_64-linux'
         at /nix/store/qrv62r966lcw0pmivndiqibn24swahzy-source/flake.nix:54:7:
           53|
           54|       lib = {
             |       ^
           55|         inherit mkLib;

       error: attribute 'x86_64-linux' missing
       at /nix/store/kwpljf3n2xlxlrq5k0p02c6kghc4n6ca-source/flake.nix:34:21:
           33|       pkgs = import nixpkgs { system = arch; };
           34|       flakeboxLib = flakebox.lib.${arch} { };
             |                     ^
           35|

why would flakebox.lib.x86_64-linux be missing?

dpc ⚡️ Hello. I'm here. Oh. I think I made backward incompat change on the master and didn't update the docs. Sorry for that!

c4lliope oh yay. I copied the full flake here: https://github.com/rustshop/flakebox/issues/209 oh, sure.

dpc ⚡️ https://github.com/rustshop/flakebox/commit/55f224911d183e126229e482795d0becb1600c5f Now the lib contains mkLib which you use to actually create the lib with given pkgs. If you're short on time, just trying using previous commit.

c4lliope ah, simple enough. I'll give it a spin.

dpc ⚡️ If you want to make the world a better place you can try to update the docs where it is different. It will be some flakeboxLib = flakeboxLib.lib pkgs; kind of thing, though you might use different names. Anyway, I'm not sure how experienced with Nix you are, there might be other adjustments needed. :D

c4lliope seems to be building now, is a really big codebase though.

dpc ⚡️ I'm using flakebox for some really big codebases indeed. https://github.com/fedimint/fedimint/blob/master/nix/flakebox.nix

c4lliope ahhhh, hold up. rustc toolchain version problem?

➜ nix build .#gitoxide
warning: Git tree '/home/calliope/disc/nvme0n1p6/code/gitoxidelabs/gitoxide' is dirty
error: builder for '/nix/store/xygc7gkl4y3nncfjvls13m9vpvsgjgvh-gitoxide-deps-0.45.0.drv' failed withexit code 101;
       last 20 log lines:
       > cargoArtifacts not set, will not reuse any cargo artifacts
       > Running phase: unpackPhase
       > unpacking source archive /nix/store/plfiwc0dm7fnzy674vdiyjg66rgk1v6f-source
       > source root is source
       > Running phase: patchPhase
       > Executing configureCargoCommonVars
       > Running phase: updateAutotoolsGnuConfigScriptsPhase
       > Running phase: configurePhase
       > will append /build/source/.cargo-home/config.toml with contents of /nix/store/g64gs1ppgvzpqi5vv42ay4dl8lmgvq24-vendor-cargo-deps/config.toml
       > default configurePhase, nothing to do
       > Running phase: buildPhase
       > +++ command cargo --version
       > cargo 1.87.0 (99624be96 2025-05-06)
       > +++ command cargo check --release --locked
       > error: rustc 1.87.0 is not supported by the following package:
       >   [email protected] requires rustc 1.88
       > Either upgrade rustc or select compatible dependency versions with
       > `cargo update <name>@<current-ver> --precise <compatible-ver>`
       > where `<compatible-ver>` is the latest version supporting rustc 1.87.0
       >
       For full logs, run:
         nix log /nix/store/xygc7gkl4y3nncfjvls13m9vpvsgjgvh-gitoxide-deps-0.45.0.drv
error: 1 dependencies of derivation '/nix/store/w04flfiqxr9hbrawvzksfyj00milh3rx-gitoxide-0.45.0.drv'failed to build

yeah, gotta go unstable.

dpc ⚡️ The toolchain shipped with flakebox might be a bit out of date. I usually bring it in separately in my projects. https://github.com/fedimint/fedimint/blob/e135fae7bdb485845dc92b5ba837f014b43e19cb/flake.nix#L17

c4lliope If I use unstable nixpkgs, is that where it's fetching from? sorry, my background is 90% nix 0% rust i'll go fenix

dpc ⚡️ Fenix is good. You can get nightly and arbitrary releases, and even mix nightly rustfmt with stable toolchain etc.

c4lliope ah, so this gitoxide codebase is a big monorepo with a bunch of sub-folders. One of those is gix-actor, and flakebox is unable to load the Cargo.toml from that pkg.

   > error: failed to load manifest for workspace member `/build/source/gix-actor`
   > referenced by workspace at `/build/source/Cargo.toml`

dpc ⚡️ Did you add it to sources? https://github.com/rustshop/flakebox/blob/261180f894d74ab95f7afbf14c7418fedb0d3cbf/flake.nix#L78

Flakebox comes with some handy source filtering to avoid rebuilding stuff when no relevant files changed. BTW. I hope you're aware that flakebox is mostly an opinionated wrapper around https://github.com/ipetkov/crane , mostly adding some stuff I needed and integrating cross-compilation.

c4lliope yeah, I printed out the crane docs to my tablet so I can read through and see if there's a more minimal option. but if this can compile before my 3pm meeting, I'm happy throwing the full arsenal at it. oh, so the main goal is to get a .wasm out of gitoxide. I'm sure I'll need to go through and add wasm_bindgen annotations, but what would the nix build ... command look like? is there a different system label, so nix can cross-compile? or do I handle that in the Cargo.toml target specification like the official docs say?

dpc ⚡️ https://github.com/fedimint/fedimint/blob/e135fae7bdb485845dc92b5ba837f014b43e19cb/.github/workflows/ci-nix.yml#L286 https://github.com/fedimint/fedimint/blob/e135fae7bdb485845dc92b5ba837f014b43e19cb/.github/workflows/ci-nix.yml#L213

c4lliope holy heck.

➜ | ls result/bin/
result/bin/ein      result/bin/gix

dpc ⚡️ ?

c4lliope build is success you all are genius. thank you so much, nixos has made getting close to rust a pain until now. before this my flakes have only been enough for "hello world", the basics from the textbook.

c4lliope avatar Oct 09 '25 18:10 c4lliope

Closes #2211 (someday)

This builds gix and ein. Before adding docs I'm going to look through the recommendations on http://crane.dev/ - they speak about adding wasm build targets, with sample code. They also have an example for monorepo workspaces that may be useful. At least, it's a simpler and smaller dependency than the flakebox that wraps it.

c4lliope avatar Oct 12 '25 18:10 c4lliope

Thanks - I set it back to draft so once you undo that I will know it's ready for another review.

Byron avatar Oct 13 '25 06:10 Byron

Flakebox Matrix: https://matrix.to/#/#flakebox:matrix.org

c4lliope avatar Oct 14 '25 21:10 c4lliope

Just for clarity: I won't be joining on matrix in preference for less real-time communication here. Thanks for your understanding.

Byron avatar Oct 15 '25 02:10 Byron

I suppose the reason for adding this flake is to promote flatebox, even though this project would most benefit from the most plain and simple flake implementation possible. If this is possible, that's great, but it would also be OK to close this PR if it then would not be fitting the original intent anymore then. Thank you.

Byron avatar Oct 21 '25 03:10 Byron

@Byron - I'd like to use normal Crane, but the docs are long and the days are short. I do plan to change this up and remove flakebox when I can.

c4lliope avatar Oct 30 '25 09:10 c4lliope

Thanks, that's great to hear!

I still wonder how well suited a flake is if I am not using it, and even with CI, I might not be able to fix it. With CI, maybe there can be a maintainer who would see failures and come to fix it.

Then again, maybe it's a "best effort" setup that may or may not work, and it gets patched up by people who want to use it on an as needed basis. Just some thoughts while we see where this PR goes :).

Byron avatar Oct 30 '25 16:10 Byron