i'm using crane to build dependencies and the finaly binary in two different steps.
after building the dependencies i'm exporting the closure using nix-store --export $(nix-store --query --requisites ./result).
since that doesn't include the cargo-deps-.drv-files and their outputs, when i run nix-store --import and building the final binary (on a different host for example) the final-binary-step builds them, creating double work.
when trying to export them as well, some of the drv-files aren't present:

export drvs=$(nix-store -q --requisites $(nix-store --query --deriver ./result/) | grep cargo-package)
export outputs$(nix-store -q --outputs $(nix-store -q --requisites $drvs)) # <- this errors since some of the drv-files aren't present in the nix store

how can i make sure to export all the drv-files and their outputs when exporting a nix store closure?

i'm using crane to build dependencies and the finaly binary in two different steps.
after building the dependencies i'm exporting the closure using nix-store --export $(nix-store --query --requisites ./result).
since that doesn't include the cargo-deps-.drv-files and their outputs, when i run nix-store --import and building the final binary (on a different host for example) the final-binary-step builds them, creating double work.
when trying to export them as well, some of the drv-files aren't present:

export drvs=$(nix-store -q --requisites $(nix-store --query --deriver ./result/) | grep cargo-package)
export outputs$(nix-store -q --outputs $(nix-store -q --requisites $drvs)) 
# the line above errors since some of the drv-files aren't present in the nix store,
# even though i'm running this after building the final closure successfully

how can i make sure to export all the drv-files and their outputs when exporting a nix store closure?

oh. actually i might not need the drvs, just their outputs:

deps=$(nix-store -r $(nix-store -q --requisites $(nix-store -q --deriver ./result/) | rg cargo-package))
final_closure=$(nix-store -q --requisites ./result/)
nix-store --export $deps $final_closure > /tmp/deps_and_final_closure

I am getting an error from a derivation I made. Specifically:

Executing cargoInstallPostBuildHook
cp: missing destination file operand after 'target/x86_64-unknown-linux-gnu/dev-tmp/'

Has anyone seen this before?

The derivation itself is pretty simple

{ pkgs, stdenv, rustPlatform, ... }:

let
fs = pkgs.lib.fileset;
src = fs.difference (fs.gitTracked ./.) (fs.unions [
  ./.gitignore
  ./flake.lock
  (fs.fileFilter (file: file.hasExt "nix") ./.)
]);
in
stdenv.mkDerivation (self: {
  cargoDeps = rustPlatform.importCargoLock {
    lockFile = ./Cargo.lock;
  };

  nativeBuildInputs = [
    rustPlatform.rust.rustc
    rustPlatform.rust.cargo
  ];

  cargoBuildType = "dev";
  buildInputs = let r = rustPlatform; in [
    r.cargoSetupHook
    r.cargoBuildHook
    r.cargoInstallHook
  ];

  name = let b = builtins; in (b.fromTOML (b.readFile ./Cargo.toml)).package.name;
  src = fs.toSource {
    root = ./.;
    fileset = src;
  };

  doCheck = false;
  meta.mainProgram = self.name;
})

Toma: I think I just found out why cargo-about has issues with git-fetched crates in nixpkgs, and wondered if you had any idea how/if fetchCargoVendor could accomodate this use-case.

The affected crates for which cargo-about fails to read the LICENSE are from a monorepo, where the LICENSE file is referenced in each crate's Cargo.toml but is located in the parent directory (the root of the repository). For fetchCargoVendor, the parent directory is the vendor directory itself, not the root of the crate's git repository, resulting in this error:

zed-editor> 2025-02-27 15:58:07.231029 +00:00:00 [WARN] failed to validate all files specified in clarification for crate pet-virtualenv 0.1.0: unable to read path '/private/tmp/nix-build-zed-editor-0.175.5.drv-0/zed-editor-0.175.5-vendor/pet-virtualenv-0.1.0/../../LICENSE': No such file or directory (os error 2)

Toma: I think I just found out why cargo-about has issues with git-fetched crates in nixpkgs, and wondered if you had any idea how/if fetchCargoVendor could accomodate this use-case.

The affected crates for which cargo-about fails to read the LICENSE are from a Cargo workspace git repo, where the LICENSE file is referenced in each crate's Cargo.toml but is located in the parent directory (the root of the repository). For fetchCargoVendor, the parent directory is the vendor directory itself, not the root of the crate's git repository, resulting in this error:

zed-editor> 2025-02-27 15:58:07.231029 +00:00:00 [WARN] failed to validate all files specified in clarification for crate pet-virtualenv 0.1.0: unable to read path '/private/tmp/nix-build-zed-editor-0.175.5.drv-0/zed-editor-0.175.5-vendor/pet-virtualenv-0.1.0/../../LICENSE': No such file or directory (os error 2)

Ok minor correction, the LICENSE file is not referenced by the crate's Cargo.toml but by the cargo-about config of the project that depends on them (in this case, zed-editor):

[pet-virtualenv.clarify]
license = "MIT"
[[pet-virtualenv.clarify.files]]
path = '../../LICENSE'
checksum = 'c2cfccb812fe482101a8f04597dfc5a9991a6b2748266c47ac91b6a5aae15383'