feat: fetch prebuilt zerokit rln, fall back to source build#3915
Conversation
|
You can find the image built from this PR at Built from bb23ee6 |
6f33eb1 to
943877c
Compare
943877c to
5bae14c
Compare
Ivansete-status
left a comment
There was a problem hiding this comment.
Thanks!
LGTM but I'd like to get feedback from @jakubgs re the nix changes.
Cheers
|
FYI, this is a common problem:
@darshankabariya please check with infra that the solution in |
| # its many crate dependencies from crates.io in one parallel burst, which | ||
| # crates.io intermittently rejects with HTTP 403 (rate limiting from the |
There was a problem hiding this comment.
Why are you adding 70 lines to flake.nix to simply do what an override of nixpkgs could have done?
Are you not aware this has been already fixed in upstream nixpkgs?
Also, even if this fix was the correct one WHY would you pollute flake.nix with this garbage instead of putting the derivation in a separate file? Or fixing it in a branch in sourc repo and updating input to use a fixed branch?
There was a problem hiding this comment.
This honestly looks like LLM slop.
There was a problem hiding this comment.
I wasn't aware of the upstream fix. I thought it was issue in crates.io's side, which is why I had the idea to use the prebuilt asset from zerokit. thinking was that it saves time by downloading instead of building locally and CI . Yes, I used Claude to implement it, but the idea was my own.
Thanks for pointing out the nixpkgs fix, I've switched to that in the follow-up.
What
The nix build now downloads the prebuilt
librlnfrom the zerokit v2.0.2 release instead of compiling zerokit from source.Why
Building zerokit from source made nix fetch ~100 Rust crates from crates.io at once. crates.io rate-limits that and returns 403, so the
liblogosdeliverynix jobs failed randomly on both Linux and macOS.Using the prebuilt binary means nix never touches crates.io, so the flake build is reliable (and faster).