[resolved] Network access while building a derivation? (lemmy.ml)

submitted 6 months ago* (last edited 6 months ago) by [email protected] to c/[email protected]

7 comments fedilink hide all child comments

edit: for the solution, see my comment below

I'm trying to package a go application (beszel) that bundles a bunch of html stuff built with bun (think, npm).

The html is generated by running bun install and bun run and then embedded in the go binary with //go:embed.

Being completely ignorant of the javascript ecosystem, my first idea was to just replicate what they do in the Makefile

postConfigure = ''
bun install --cwd ./site
bun run     --cwd ./site build
''

but, since bun install downloads dependencies from the net, that fails.

I guess the "clean" solution would be to look for buildNpmPackage or similar (assuming that exists) and let nix manage all the dependencies, but... it's some 800+ dependencies (at least, bun install ... --dry-run lists 800+ things) so that's a hard pass.

I then tried to look at how buildGoPackage handles the vendoring of dependencies, with the idea of replicating that (it dowloads what's needed and then compare a hash of what was downloaded with a hash provided in the nix package definition), but... I can't for the life of me decipher how nixpkgs' pkgs/build-support/go/module.nix works.

Do you know how to implement this kind of vendoring in a nix derivation?

top 7 comments

sorted by: hot top new old

[-] [email protected] 2 points 6 months ago

Maybe someone else will have a better answer but in similar situations I've seen the derivation simply downloads a compiled release directly.

I ran into the same issue trying to package silverbullet which uses deno and I gave up, later I saw it was added to nixpkgs by just downloading the github release.

[-] [email protected] 1 points 6 months ago

Found the solution (I think): basically it should just work as expected if you just add outputHashAlgo, outputHashMode and outputHash to your derivation.

documentation
article

[-] [email protected] 2 points 6 months ago

That will only work if it is reproducible. Given that it downloads random shit from the internet, that's unlikely.

To package this properly, you need to build a derivation that can use a lock file to bundle the deps into some sort of stable format. This is how go's vendoring works.

[-] [email protected] 1 points 6 months ago

Given that it downloads random shit from the internet

You seem to trust the javascript ecosystem just as much as I do :)

Jokes aside, the repo has a lock file so it should actually be fine (time will tell)

[-] [email protected] 1 points 6 months ago

Having a record which defines exactly what to fetch is the necessary condition, not the sufficient condition.

The actual artifacts fetched to disk must be stable, not just the record.

[-] [email protected] 0 points 6 months ago

Until someone rewrites git history and screws up your build

[-] [email protected] 1 points 6 months ago

That'd hit the source fetcher just as much. That's an issue on a different layer.

this post was submitted on 08 Nov 2024

5 points (100.0% liked)

Nix / NixOS

2236 readers

4 users here now

Main links

Videos

founded 2 years ago

MODERATORS

[email protected]