In reply to @julius:mtx.liftm.de
patching script interpreter paths in /nix/store/…-rustc-1.80.1-doc Why do you take like 3 minutes… :/

In reply to @artturin:matrix.org
Yep, also supports regex.

I've ended up just adding the fenix toolchain as a home manager package

  home.packages = with pkgs; [
    inputs.fenix.packages.x86_64-linux.stable.toolchain

The nixpkgs rustc and cargo packages just didn't seem to setup the necessary stuff to get picked up by rust-rover or provide standard library such that it would be found.

In reply to @artturin:matrix.org
Yep, also supports regex.

I've ended up just adding the fenix toolchain as a home manager package

  home.packages = with pkgs; [
    inputs.fenix.packages.x86_64-linux.stable.toolchain

The nixpkgs rustc and cargo packages just didn't seem to setup the necessary stuff to get picked up by rust-rover or provide standard library such that it would be found.. This one line magically make everything work perfectly

I was looking through the recent darwin rework when I encountered an hook which gave me an interesting idea.
https://github.com/nixOS/nixpkgs/commit/121149836ef2c33bb62abd323eb95780ac7d59a2
This generates hashes in a script using openssl instead of letting nix fetch and hash the files.
Using this idea we might be able to get rid of importCargoLock usage when it's forced by git dependenies.
(About 270 lockfiles exists because of git dependencies, while only about 65 because of upstream not having the lockfile)

This may be flawed somewhere but the main idea would be to somehow implement importCargoLock in a non-nix language .
If the script encounters a git-dependency, it will fetch it, hash it and throw a hash mismatch error just like with the hook I mentioned above. Then, we could add the hash to outputHashes, which would then generate a .json file that our script will read, and check if the hash still matches.
The non-git dependencies should all have a checksum, those are probably easy to validate.
Finally, the script sets everything else up (e.g. place directories where they belong, create .cargo/config.toml)
As all of this is inside a FOD, a FOD hash will also be generated. This is the only part where the API of this new importCargoLock-like helper would deviate from importCargoLock.

If anyone has some additional ideas, please share them.

I'm aware that there's also another idea where there would be only ""One Big Lockfile"" for all cargo stuff.

https://github.com/rust-lang/cargo/pull/11414
I think this is the original PR that broke git stuff.

AFAICT fetchCargoTarball only broke because it relied on cargo's built-in vendoring method, which happened to change the Cargo.toml files (?)
Since neither importCargoLock or this new thing actually use cargo, it should be fine, I think.