| 20 Feb 2025 |
Niklas Korz | in that case you could probably just copy mkRustBin from flake.nix: | 19:18:24 |
Niklas Korz | # Builder to construct `rust-bin` interface on an existing `pkgs`.
# This would be immutable, non-intrusive and (hopefully) can benefit from
# flake eval-cache.
#
# Note that this does not contain compatible attrs for mozilla-overlay.
mkRustBin =
{ distRoot ? defaultDistRoot }:
pkgs:
lib.fix (rust-bin: import ./lib/rust-bin.nix {
inherit lib pkgs;
inherit (rust-bin) nightly;
manifests = mkManifests distRoot;
});
| 19:18:27 |
Niklas Korz | well, of course you'll have to replace ./lib/rust-bin.nix with ${rust-overlay}/lib/rust-bin.nix here | 19:18:46 |
Charles | that would work i guess but is unfortunate | 19:19:43 |
Niklas Korz | then you can do something like
rust-stable = (mkRustBin { } pkgs).stable.latest.default
| 19:20:15 |
Niklas Korz | * then you can do something like
rust-stable = (mkRustBin { } pkgs).stable.latest.default;
| 19:20:19 |
Charles | actually it would probably be easiest to just import lib/rust-bin.nix directly | 19:20:35 |
Charles | since i would already have a nixpkgs at the point i would need to call this | 19:20:55 |
| 21 Feb 2025 |
| thou-vow joined the room. | 05:49:50 |
Niklas Korz | Concerning https://github.com/NixOS/nixpkgs/pull/383717#issuecomment-2673988082 :
Was the linker setting in .cargo/config.toml previously ignored and now it's somehow picked up by buildRustPackage? | 09:32:47 |
Niklas Korz | Or was clang previously accidentally exposed to buildRustPackage? 🤔 | 09:36:47 |
kraem | 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?
| 12:58:43 |
kraem | * 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?
| 13:00:04 |
kraem | 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
| 13:35:18 |
kraem | that sped things up :) | 13:36:00 |
| Morj left the room. | 13:55:13 |
rosssmyth | 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?
| 18:33:46 |
rosssmyth | 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;
})
| 18:37:44 |
rosssmyth | I saw this before when I was doing some refactoring but was able to just revert the change so I ignored it | 18:38:20 |
rosssmyth | * I saw this before when I was doing some refactoring on another project but was able to just revert the change so I ignored it | 18:38:29 |
| 22 Feb 2025 |
Charles | i got this to work fwiw: https://gitlab.computer.surgery/charles/dotfiles/-/blob/27483e3a0aca60882d731c271f57ea95dd8da3c2/nix/default.nix#L28-39 | 02:25:47 |
Charles | i opened an issue about this uh usability papercut with an explanation of how to do it so others can use it as a reference: https://github.com/oxalica/rust-overlay/issues/209 | 02:36:24 |
| 23 Feb 2025 |
| @linucifer:envs.net removed their profile picture. | 17:24:50 |
| @linucifer:envs.net removed their display name linucifer. | 17:24:54 |
| @linucifer:envs.net left the room. | 17:24:57 |
| 24 Feb 2025 |
| wilfredallyn set a profile picture. | 00:05:17 |
| 26 Feb 2025 |
| samw joined the room. | 09:50:20 |
| 27 Feb 2025 |
Niklas Korz | 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)
| 16:08:10 |
Niklas Korz | * 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)
| 16:08:32 |
Niklas Korz | 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'
| 16:11:18 |