Any improvements I should make to my flake.nix

[dpc]

I used to use lorri + naersk + fenix as my nix flake for Rust combo. I'm trying to switch to crane.

I'm in the middle of nixifying a project I'd like to contribute. The flake.nix is here:

https://github.com/mycitadel/mycitadel-desktop/pull/41/files#diff-206b9ce276ab5971a2489d75eb1b12999d4bf3843b7988cbe8d687cfde61dea0

In particular:

• Is there any way to simplify sharing the buildInputs and nativeBuildInputs between phases? I kind of wish inherit ... took care of it automatically or something.
• Any better way to plug in fenix toolchains in there?

[ipetkov]

Is there any way to simplify sharing the buildInputs and nativeBuildInputs between phases? I kind of wish inherit ... took care of it automatically or something.

By default, if you call buildPackage or cargoBuild without specifying a value for cargoArtifacts, they will automatically set cargoArtifacts = buildDepsOnly args where args is whatever you passed into buildPackage/cargoBuild.

For example, your flake can be simplified to:

{
  description = "MyCitadel Wallet app for Linux, Windows & MacOS desktop made with GTK+ ";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs";
    flake-utils.url = "github:numtide/flake-utils";
    crane.url = "github:ipetkov/crane";
    crane.inputs.nixpkgs.follows = "nixpkgs";

    flake-compat = {
      url = "github:edolstra/flake-compat";
      flake = false;
    };

    fenix = {
      url = "github:nix-community/fenix";
      inputs.nixpkgs.follows = "nixpkgs";
    };

    naersk = {
      url = "github:nix-community/naersk";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };

  outputs = { self, naersk, nixpkgs, flake-utils, flake-compat, fenix, crane }:
    flake-utils.lib.eachDefaultSystem (system:
    let
      pkgs = import nixpkgs {
        inherit system;
      };
      fenix-pkgs = fenix.packages.${system};
      fenix-channel = (fenix-pkgs.stable);

      craneLib = (crane.mkLib pkgs).overrideScope' (final: prev: {
        cargo = fenix-channel.cargo;
        rustc = fenix-channel.rustc;
      });

      mycitadel = craneLib.buildPackage {
        src = ./.;
        pname = "mycitadel";
        buildInputs = [
          pkgs.pango
          pkgs.atk
          pkgs.gtk3
        ];
        nativeBuildInputs = [
          pkgs.pkgconfig
          fenix-channel.rustc
        ];
      };

    in {
      defaultPackage = mycitadel;

      devShell = pkgs.mkShell {
        inputsFrom = [ mycitadel ];

        nativeBuildInputs = [
          fenix-pkgs.rust-analyzer
          fenix-channel.rustfmt
          fenix-channel.rustc
          fenix-channel.cargo
        ];
        RUST_SRC_PATH = "${fenix-channel.rust-src}/lib/rustlib/src/rust/library";
      };
  });
}

Any better way to plug in fenix toolchains in there?

There's definitely room for improvement for plugging in different toolchains, especially since they all have slightly different initialization flows. That said, crane takes the approach of using an overlay-like pattern which is a familiar topic in the Nix ecosystem. Specifying the exact cargo/rustc versions you want to use via craneLib.overrideScope' is the simplest way across all derivations in the flake.

But if anyone has other ideas, please open an issue!

[dpc]

But if anyone has other ideas, please open an issue!

I only meant to ask if what I wrote is a correct and idiomatic way to do it.

But since you mention it, the (crane.mkLib pkgs).overrideScope' (final: prev: { is really long, includes mkLib function call, then some weird long field with a ' and an argument being a lambda or something? Really weird. I have some guesses why this is the case, but maybe there should be just a custom shorthand functions for 99% of users that will want to override cargo and rustc to use a different Rust version.

[ipetkov]

Thanks for the feedback! I'll think about some API improvements especially if it turns out to be common to use custom toolchains.

then some weird long field with a ' and an argument being a lambda or something?

Yeah the naming is a bit unfortunate as it comes from nixpkgs scopes. The final: prev: lambda behaves just like you'd expect overlays to work, so it is possible to layer multiple overrides if necessary

[dpc]

Honestly speaking, I don't know how overlays work. I just want to write Rust under NixOs. :D . I would expect a lot of people are going to be like me.