Nix Rust | 667 Members | |
| Rust | 149 Servers |
| Sender | Message | Time |
|---|---|---|
| 18 Mar 2025 | ||
In reply to @tomasajt:matrix.orgYep, that's exactly it. Guess we just update the lockfile ourselves and commit to Nixpkgs? | 10:21:36 | |
Creating a .patch is less lines overall | 10:22:02 | |
| Also, maybe open an issue upstream if you have the time | 10:22:40 | |
In reply to @tomasajt:matrix.orgAlready one up. | 10:22:49 | |
* Creating a .patch is less lines overall (remember to use cargoPatches instead of patches) | 10:23:48 | |
In reply to @tomasajt:matrix.orgUh, the patch ended up being around 400 lines longer | 10:28:32 | |
I still recommend using a .patch because you'd have to use depsExtraArgs if you wanted to use postPatch | 10:42:08 | |
| Yeah i'm going with the patch. | 10:42:24 | |
| why is it so hard for upstreams to commit their lockfiles is beyond me | 10:42:49 | |
| I'm guessing in this case it's because the ./below/Cargo.toml file was not next to the ./Cargo.lock file, and they only commited changes to the ./below directory | 11:02:18 | |
| 19 Mar 2025 | ||
| There may be an issue with rust bindgen packaging (or an issue with rust bindgen itself) At first I thought meson is hanging but after some investigation I figured out bindgen is hanging because it’s trying to run llvm-config. Which because it’s a cross compile, is an x86_64-linux binary. Instead of running llvm-config-native. Once I set LLVM_CONFIG_PATH variable the build succeeded. I don’t think that should be happening? Part of it is probably that I have misconfigured binfmt and running x86 binaries hangs, but bindgen should by default run llvm-config-native when cross compiling, right? Instead of trying to run llvm-config, which in this case is compiled for the wrong architecture | 10:56:11 | |
| 22 Mar 2025 | ||
| what is the most popular Rust library for working with Nix? I am teaching myself Rust and I want to build a thing that can read from an OCI registry and write to the Nix Store.. with an eventual goal of maybe allowing the OCI registry to be used for substitution... but these are all kind of lofty goals.. I am very much a Rust novice.... this seems simple to do but I don't know what I don't know. I've already got a thing hobled together allowing me to write arbitrary files to an OCI registry.. | 15:33:04 | |
| You'll really want to go through libstore for this | 15:33:56 | |
| Via rust-cxx or sometihg | 15:34:17 | |
| * Via rust-cxx or something | 15:34:19 | |
Or just call nix-store --add-fixed or whatever | 15:34:29 | |
| ok i'll check that out thanks... ahh thats a good idea.. | 15:34:43 | |
| But really the big problem would be actually making the planner aware of other types of substituters | 15:34:55 | |
| You'd have to write your own store subclass and that's C++ | 15:35:04 | |
| Even Lix doesn't have enough Rust infrastructure to do that in Rust | 15:35:19 | |
| sounds like a learning opportunity | 15:35:27 | |
| But also I'd argue there's a pretty big impedance mismatch between OCI semantics and Nix stores | 15:35:59 | |
| my short term goal would simply be hey can I take a registry layer and store it in Nix and it be equivalent to something built purely with Nix. | 15:36:09 | |
| Nix doesn't really need anything the OCI spec provides | 15:36:12 | |
| Except copying blobs around | 15:36:21 | |
| yea I would be treating the OCI registry as a blob store.. | 15:36:34 | |
| And there are significantly easier ways to copy blobs around | 15:36:48 | |
| the idea being that I would be able to leverage existing infra for storing Nix stuff because everyone already talks OCI registry.. so I could store it there and then have a thing that pulls it down.. to a local Nix store.. maybe making it easier for air gapped environments or just playing nice with places that don't do Nix | 15:37:57 | |
| I feel like S3, which already exists, is kind of that already? | 15:38:16 | |
| oh yea I actually didn't know you could store Nix store in S3 | 15:38:32 | |