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'

In reply to @niklaskorz:korz.dev

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)

There is a PR that tries to fix the issue with symlinks. (Can't send the url atm)

Though, if it's in the config file, I doubt it solves that.

Would be interesting to see what upstream carg does about this. (fetchCargoTarball or the cargo vendor command)

A change could be made to fetchCargoVendor that doesn't only copy a crate's subtree, but the entire git tree. This would break the expectation of having all crates in the root of cargoDeps. Though this is something we've been considering doing anyways (to allow duplicate packages with the same version).
Though, this might cause more storage usage, since complete git trees will end up in cargoDeps. This isn't that big of a problem though.

I'm very satisfied with the fact that we can do all these changes without having to worry about breaking the FOD hash.

that being said, it doesn't re-request if the file didn't change but the flake did

so doing an allow for some project that just uses use flake; means you allowed any flake it could have, which in practice means not re-requesting on code changes

(though in practice i don't think this is much of an issue if it's a project where you would execute the code of it anyways, the allow is just to stop you getting owned by a direnv you don't expect)

but yeah ultimately i don't think it's a problem
because like, if someone gets malicious code into the flake.nix of, say, rust
or servo

they could also just insert malicious code into the project itself and own a lot more people than just nix users