| 25 Nov 2025 |
 WeetHet | This should help with merge conflicts I think, no? | 19:56:20 |
 rosssmyth | The idea of processing all the crates into one file is to eliminate merge conflicts from being possible in the first place | 19:58:38 |
| rosssmyth | Since the maintainer(s) of the package set would just regenerate the entire file every week or so | 19:59:03 |
| rosssmyth | Another idea I have been ruminating upon is something like:
- Create a package set like
rustCrates, but do not populate it with anything initially
- Create builders similar to the above idea (add the source, add a symlink builder for cargo-vendor)
- When someone wants to add a Rust package, a new process is used:
- Use a tool that processes lock files, and checks if the required crates are in the package set
- If not, it emits the latest semver-compatible to a
by-name-like directory tree using the crates.to name
- Each ~week a program similar to the one I made is ran:
- For each crate in the package set, update each semver to the latest-compatible one, should be relatively fast since no downloading is required, the version is in the index, and the required hash is in the index
- Write the latest semver-compatible-version and hash in the files
- Check the rustsec db as well, and if crates are yanked.
- For program dependencies in which the semver that is required is already in the pkgset, they do not touch the package set. If they need to wait a ~week for the next version to the bumped to that is fine.
| 20:09:31 |
| WeetHet | Yeah that's basically what I wanted to achieve with my script | 21:07:07 |
| 28 Nov 2025 |
|  anniecrudeness joined the room. | 18:06:53 |
| 29 Nov 2025 |
|  amadaluzia changed their profile picture. | 11:40:45 |
| 30 Nov 2025 |
|  Aditya Kompella joined the room. | 22:49:08 |
| 1 Dec 2025 |
| Aditya Kompella | Hello. I've been using nix and nixos for a while. I noticed that in the changelog for the new stable release that there was a few rust projects. How can I get involved as a newcomer, with some decent rust and nix experience? | 01:16:38 |
 Acid Bong | In reply to @akompella:matrix.org
Hello. I've been using nix and nixos for a while. I noticed that in the changelog for the new stable release that there was a few rust projects. How can I get involved as a newcomer, with some decent rust and nix experience? everyone can submit their fixes to Nixpkgs. if you wanna take responsibility for specific packages/modules, add yourself to their maintainers (see readmes under maintainers and pkgs on how) | 04:47:35 |
| Aditya Kompella | Thank you. I am planning currently to submit a PR to nixpkgs for a package I haven't seen on there, and I'll take a look at taking responsibility for other packages once I go through the process once myself, I hadn't considered that. However, I was asking more about the nix / nixos tooling / projects rather than projects in nixpkgs. | 08:34:44 |
 K900 | Nixos tooling that is Rust mostly lives inside nixpkgs | 09:03:53 |
| K900 | Nix itself doesn't use Rust | 09:03:58 |
| K900 | Lix, a Nix fork, uses Rust somewhat, and plans for more Rust in the future | 09:04:10 |
 John Ericson | See also the recent activity in https://github.com/nix-community/harmonia | 09:06:34 |
| John Ericson | An all-Rust daemon should not be much more work away | 09:07:03 |
| 3 Dec 2025 |
 Gaétan Lepage | I have set cargoCheckType = "debug" and the env variable still shows "release". Are we supposed to set it as an env variable?
I saw some derivations that set cargoCheckType in their attrs... | 18:07:18 |
| rosssmyth | Should work unless you are using buildRustPackage then you need to set checkType and not cargoCheckType | 18:15:44 |
|  neobrain joined the room. | 21:27:05 |
| neobrain | When writing a flake.nix for a Rust project I'm authoring (i.e. it'll bundle the flake), are there reasons to use anything other than nixpkgs's buildRustPackage? | 22:20:37 |
 dish [Fox/It/She] | if you need a nightly or beta version then you'd be better off with an external project | 22:26:55 |
| dish [Fox/It/She] | i dont have a preference personally since I dont use them | 22:27:03 |
| dish [Fox/It/She] | but that's the main reason to use them | 22:27:09 |
| dish [Fox/It/She] | since they have binary caches so you dont have to build rustc from source(which would happen if you overrode nixpkgs' rustc version) | 22:27:29 |
| neobrain | Oh, I was thinking among the other nix options (naersk, carnix, etc) that are listed on the wiki | 22:32:52 |
| rosssmyth | Yes!
- Currently if cross compiling for mingw
buildRustPackage makes it a bit worse than the other builders
buildRustPackage does no caching of dependencies. This means that every time you run nix build it will rebuild every dependency. The others generally do not to varying levels of granularity.
For projects I author I generally use Crane. You can do some smart caching so that it's pretty fast in CI.
| 22:33:06 |
| neobrain | For development I'm just going to nix develop either way | 22:33:08 |
| neobrain | * Oh, I was thinking among the other nix options (naersk, crane, etc) that are listed on the wiki | 22:33:42 |
| neobrain | Interesting point about caching of dependencies. I would've assumed the mapping of Cargo.lock would create a separate nix store entry for each dependency (and hence trivially cache things), but I'm probably underestimating the problem space :) | 22:35:27 |
| dish [Fox/It/She] | sorry, thats what I meant. I see the main value prob of the {naersk,crane,fenix,etc} solutions as being that they allow using betas/nightlys if wanted | 22:35:42 |
