Dependency Hell

[quixoticgeek]

Installing cookcli on a fresh armbian install via "cargo install cookcli" results in a total of 581 items being installed. This seems incredibly excessive for a simple recipe manager.

Have they all been vetted and checked?

Are they all really necessary?

[quixoticgeek]

Not only does it pull in 580 packages, but it then fails to install.

error: failed to load bitcode of module "cooklang_find-c71ff486b3170a61.cooklang_find.5beffde5e765e265-cgu.0.rcgu.o": 

error: could not compile `cookcli` (bin "cook") due to 1 previous error
error: failed to compile `cookcli v0.32.1`, intermediate artifacts can be found at `/tmp/cargo-installwdiPPp`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.

And the stuff it installs trying to make the recipe manager work?

du -sh /tmp/cargo-installwdiPPp/
1.3G    /tmp/cargo-installwdiPPp/

[Murgalha]

I also faced the same problem, lots of dependencies and failing to install because of this bitcode module. I found out that running cargo install cookcli --locked installs it fine without errors, but I'm no Rust expert to know the quality of the solution

[dubadub]

Thanks for raising this. Both halves are fair, and the install failure is a bug on our side. Let me take them separately.

The build failure

failed to load bitcode of module ... .rcgu.o comes from exactly one place in rustc: the fat LTO path (run_fat in rustc_codegen_llvm/src/back/lto.rs). We opt into it ourselves:

[profile.release]
lto = true          # fat LTO
codegen-units = 1

That is the highest-peak-memory configuration available, and we are asking it to LTO ~400 crates in one go.

Note that the error ends with ": and an empty LLVM message. That means LLVM was handed a buffer that isn't valid bitcode at all — a truncated .rlib — rather than hitting a real codegen bug (those print a concrete diagnostic like Invalid cast).

Where does a truncated rlib come from? Armbian mounts /tmp on zram — a RAM-backed block device sized to RAM/2 by default (armbian-zram-config). And cargo install puts its build directory under $TMPDIR unless told otherwise, which is exactly why yours landed in /tmp/cargo-installwdiPPp. So your 1.3 GB of build artifacts were being written into RAM, on a board that simultaneously needed a multi-gigabyte heap for fat LTO. Something had to give, and the rlib lost.

To get it installed right now, move the build directory off zram:

CARGO_TARGET_DIR=~/.cache/cookcli-build cargo install cookcli --locked

and if memory is still tight, turn off LTO for the build:

CARGO_PROFILE_RELEASE_LTO=false CARGO_PROFILE_RELEASE_CODEGEN_UNITS=16 \
CARGO_TARGET_DIR=~/.cache/cookcli-build cargo install cookcli --locked

@Murgalha — --locked most likely helped you by accident. It doesn't change the LTO settings or where the build directory lives; it just resolves a slightly smaller dependency set, which can be enough to tip a machine sitting right at the memory cliff. Worth using regardless, but it isn't the actual fix.

What we'll change: move to lto = "thin", stop pinning codegen-units = 1, and publish prebuilt aarch64/armv7 binaries so nobody has to fat-LTO 400 crates on an SBC in the first place.

The dependency count

581 is Cargo's Locking N packages line — the resolver graph across all platforms, including Windows-only crates and dev-dependencies that are never compiled on your board. The number actually compiled for aarch64-unknown-linux-gnu is 412. Smaller, still too many. The complaint stands.

Here is where they go, measured by building the manifest up one layer at a time:

Layer	crates	cumulative
Core recipe CLI — parser, recipe discovery, clap, serde, output formatting	131	131
+ web server (axum, askama, tower-http, tokio "full")	+74	205
+ HTTP client (reqwest + rustls)	+43	248
+ website import, sync client, LSP server, self-update, i18n, reports	+164	412

So a recipe manager is about 131 crates. The other ~280 are things cookcli grew: cook server (a web UI), cook import (scrapes recipe sites), cook lsp (a language server), cook login (sync), cook update (self-update). Each is a real feature someone asked for — but today only sync and self-update are behind Cargo features. If all you want is cook recipe and cook shopping-list, you are still compiling an HTTP stack, a TLS stack, an HTML scraper and a language server. That's on us, and it's the legitimate core of your point.

What we'll change: feature-gate server, import and lsp the same way sync and self-update already are, so cargo install cookcli --no-default-features gives you a lean CLI. (The exact default set is still up for discussion — most people installing from crates.io probably do want the server.)

Separately, while digging I found that cooklang-find is currently compiled twice, at 0.5 and 0.6, because cooklang-reports still depends on the 0.5 line. A fitting coincidence, given cooklang_find is the crate named in your error. That one is free to fix and I'll do it.

Have they all been vetted and checked?

Honestly: not crate-by-crate. They are the mainstream ecosystem (tokio, axum, serde, clap, reqwest/rustls) plus their transitive deps, and we don't run a supply-chain review process today. I won't pretend otherwise. Reducing the surface area, as above, is the more useful answer than claiming an audit we haven't done.

[dubadub]

Update, plus two corrections to my comment above.

Correction 1: we already publish ARM binaries. I said we would start. We already do — aarch64-unknown-linux-musl and arm-unknown-linux-musleabihf have been in the release workflow all along. The real failure is that the README offers cargo install as an equal option with no warning, so people compile 400 crates on an SBC instead of downloading a binary. That is a docs bug, and it is fixed in #368.

Correction 2: the cooklang-find duplicate is not a one-line fix. I called it free. It is not: cooklang-reports 0.5.0, the current release, is still on the cooklang-find 0.5 line, and cookcli is pinned to cooklang-reports 0.2.2. Deduplicating takes a three-repo chain. Sorry for the sloppy claim.

What is open

The build failure — #367 moves the release profile off fat LTO, which is what makes the link step need a multi-GB heap. Costs ~18% binary size (19.6 → 23.2 MB); that trade is on the PR for discussion. #368 fixes the install docs and documents the Armbian /tmp-on-zram trap.

The dependency count — #369 puts server, import and lsp behind Cargo features (they were always-on; only sync and self-update were gated):

	crates	binary
default — unchanged, still every command	412	23 MB
--no-default-features	225	9 MB

So cargo install cookcli behaves exactly as before, and anyone who just wants cook recipe and cook shopping-list can now skip the HTTP server, the TLS stack, the HTML scraper and the language server.

That PR also turned up a latent bug, which is the most useful thing to come out of this issue. cooklang's bundled_units feature — the unit database behind quantity scaling and unit normalisation — was never declared by cookcli. It was reaching us purely by Cargo feature unification, because cooklang-language-server and cooklang-reports pull cooklang with default features. Gate lsp off and cook recipe output silently changes:

   "quantity": {
-    "scalable": false,
-    "unit": "c",
+    "scalable": true,
+    "unit": "cups",

Any dependency change that dropped those crates would have quietly altered recipe output. Now declared where it is actually used.

Deduplication — cooklang-find#8 and cooklang-reports#8. Beyond the duplicate cooklang-find, it turns out cooklang-find depends on uniffi unconditionally — it exists to generate the iOS/Android bindings, but every Rust consumer compiles it plus its bindgen chain (goblin, weedle2, cargo_metadata). Making it optional and deduplicating removes it from cookcli's graph entirely.

Have they all been vetted and checked?

Still no, and I am not going to claim otherwise. But --no-default-features now nearly halves what you have to trust, and the count on the default path will keep coming down.

Thanks for the push — the bundled_units bug in particular would not have surfaced without it.