Seeking Feedback: What is needed for a 1.0 release?

[Peter Kolloch]

What does crate2nix miss for feeling ready for a 1.0 version?

I have plenty ideas for additional features but this is more about

• future proofing the "public" attributes of the generated build files,
• future proofing configuration (I am actually thinking about moving to a crate2nix.toml file instead of command line arguments),
• generally having a solid basis so I can avoid incompatible changes in the future,
• making crate2nix rock solid for the use cases it already provides,
• good enough documentation.

What do you think?

[Matthew Doty]

Thank you @kolloch for making this tool!

Here is my two cents.

Nix could be used for configuration rather than a crate2nix.toml file.

This is what callCabal2nixWithOptions does.

Here is a prototype callCrate2nix I am using:

{ pkgs ? import <nixpkgs> {},
  lib ? pkgs.lib }:

let
  crate2nix = import ./nix/crate2nix.nix {};
  callCrate2nix = { src }: pkgs.stdenv.mkDerivation ({
    name = "default.nix";

    buildCommand = ''
    # crate2nix needs to open Cargo.lock with write permissions
    chmod u+w ${src}/Cargo.lock
    ${crate2nix}/bin/crate2nix generate -f ${src}/Cargo.toml -o $out
    '';
  });
  project = callCrate2nix { src = ./.; };
  crate2nix_package = (pkgs.callPackage project {}).rootCrate.build;
in with pkgs ; pkgs.symlinkJoin {
  name = crate2nix_package.name;
  paths = [ crate2nix_package ];
  buildInputs = [ makeWrapper cargo ];
  postBuild = ''
    # Fallback to built dependencies for cargo and nix-prefetch-url
    wrapProgram $out/bin/${crate2nix_package.name} \
       --suffix PATH ":" ${lib.makeBinPath [ cargo nix ]}
    rm -rf $out/lib $out/bin/${crate2nix_package.name}.d
  '';
}

The callCrate2nix could be expanded with additional options. These would be passed to crate2nix as command line arguments. Another would be to follow the example set by callCrate2nixWithOptions.

[Peter Kolloch]

@xcthulhu Thanks, I think about that. Is this the standard pattern for generating nix and using it in the same build?

[Matthew Doty]

Is this the standard pattern for generating nix and using it in the same build?

Hmm... I think yarn2nix works in a similar way, yeah.

Calling the yarn2nix.mkYarnPackage in a derivation leaves a few <hash>-yarn.nix files in the nix store after it runs. My way could use some polish to do the same.

I'm not sure if callCabal2Nix does the same thing or not.

[Justus K]

Two things I really need for this project to be usable in most of my projects:

• Flakes support. I really like to use Flakes instead of other things like niv.
• Support for -Zbuild-std #161. I have many projects that use no_std environments, and they would be awesome to use with Nix, but currently, no "Nixify your cargo project" package supports building with build-std

[mitchmindtree]

Just a related thought - I wonder if getting this to 1.0 (or even just making progress) would be a suitable project for Summer of Nix? If I had a bit more time, I feel like this would be a nice candidate to propose :)

[Peter Kolloch]

@mitchmindtree Nice idea, I would be open to tutoring/supporting an intern if they really spend a considerable time on this (otherwise onboarding overhead might be a big much).

[John Ericson]

I as looking into -Zbuild-std a bit, but I feel like the main issue is how -Zbuild-std works on the Cargo side: the workspaces are completely independent and then mashed together. That means stuff like explicit stdlib deps adjusting e.g. stdlib features won't work.