# Status of lang2nix approaches

**URL:** https://discourse.nixos.org/t/status-of-lang2nix-approaches/14477
**Category:** Uncategorized
**Created:** [August 10, 2021, 10:25am UTC](https://discourse.nixos.org/t/status-of-lang2nix-approaches/14477 "2021-08-10T10:25:44Z")
**Posts on this page:** 1
**Showing post:** 20

<div class="post-metadata">

### Author: ![danieldk](https://discourse.nixos.org/user_avatar/discourse.nixos.org/danieldk/32/31405_2.png) [@danieldk](https://discourse.nixos.org/u/danieldk)
#### Post date: [August 14, 2021, 8:35am UTC](https://discourse.nixos.org/t/status-of-lang2nix-approaches/14477/20 "2021-08-14T08:35:03Z")

</div>

> [@matklad](#):
>
> Cargo ([crates.io](http://crates.io)) packages are immutable – once a particular version of a package is published, it is frozen and can’t be changed/deleted.

Agreed. However, the main issue are vendoring changes. E.g. relatively recently there was a regression in `cargo vendor` that changed permissions when unpacking sources. Many derivations that were updated during that window had wrong `cargoSha256`s once the regression was fixed. I recently checked the `cargoSha256`/`cargoHash` of all `buildRustPackage` derivations and [more than 300 had incorrect hashes](https://github.com/NixOS/nixpkgs/pull/122016/files). We have had to fix `cargoSha256`s several times over the last couple of years.

> [@matklad](#):
>
> My understanding is that nixpkgs and Cargo are fundamentally different in this respect. In Nix, every package specifies concrete dependencies. In Cargo, a package specifies _constraints_ on the packages (version ranges), and it’s up to Cargo to run a version resolution algorithm and to select concrete packages given the current state of the registry (the state of all packages published so far).

But nixpkgs is pretty much only packaging binary crates, which have dependencies locked through `Cargo.lock`. So, for that use case Cargo and Nix both specify concrete dependencies.

To me, the primary issues are:

1. `Cargo.toml`/`Cargo.lock` do not provide enough metadata to make derivations for all dependencies at eval time (e.g. we do not know what dependencies are activated through features). We need to download and unpack all crates and read their `Cargo.toml`s, e.g. through `cargo metadata`, to get the necessary metadata. This means that either the derivations should be generated through a separate step (e.g. running `crate2nix`) or by using IFD.
2. Generating derivations for a substantial part of [crates.io](http://crates.io) would probably add a lot of eval time to nixpkgs. This could have been acceptable with lazy eval, but as Rust trickles through the FLOSS ecosystem, it would add a lot of transitive dependencies (e.g. building GHC now depends on Rust/Cargo/various crates). Now such dependencies are cheap, because in the Rust build hooks we defer all dependency handling to Cargo. Though I guess flakes will make this more feasible, because evaluations can be cached.

---

_[View the full topic](https://discourse.nixos.org/t/status-of-lang2nix-approaches/14477)._