Seeking Feedback: What is needed for a 1.0 release? about crate2nix HOT 7 OPEN

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

from crate2nix.

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.

from crate2nix.

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

from crate2nix.

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.

from crate2nix.

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 :)

from crate2nix.

@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).

from crate2nix.

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.

from crate2nix.