Open fdietze opened 6 days ago
@fdietze devbox should be using the latest nixpkgs commit that has the requested version for each package. So if you add python@latest
and go@latest
you should end up with the same nixpkgs commit (probably the head of nixpkgs-unstable).
However, once a package is added it gets locked and the nixpkgs commit will never change unless devbox update
is run. So if you added python@latest
yesterday and go@latest
today you might get two separate commits. Running devbox update
should synchronize them back to the same commit.
If you're not seeing this behavior, let me know. If you paste your devbox.json and devbox.lock I can help debug further.
Cool, that would be the right approach!
I just tried to run devbox update
in this repo: https://github.com/social-protocols/jabble2 and checked the lock-file. The resolved-hashes for all packages are different.
What problem are you trying to solve?
When using devbox in CI to build a production release, I often see transitive dependencies of the same version downloaded multiple times, for example:
This is creating lots of traffic and big caches.
It happens, because different packages listed in devbox.json are pointing to the commit hash in nixpkgs corresponding to their version. Even if that version is resolved from
latest
.What solution would you like?
Here is an idea, which I'm not sure how practical it is:
Pin all packages using
@latest
version to the same nixpkgs commit hash.This would allow them to share most of their transitive dependencies and therefore reduce download sizes.
Alternatives you've considered
Ditching devbox and using flakes directly, with extra inputs for software that I want to pin to a specific version.