Nix / NixOS

1762 readers

29 users here now

Main links

Videos

founded 1 year ago

MODERATORS

erlingur@programming.dev

ballmerpeaking@programming.dev

WhiteBlackGoose@programming.dev

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

submitted 1 week ago* (last edited 1 week ago) by gomp@lemmy.ml to c/nix@programming.dev

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 controversial new old

[–] Buckshot@programming.dev 2 points 1 week ago (1 children)

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.

[–] gomp@lemmy.ml 1 points 1 week ago (1 children)

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

[–] Atemu@lemmy.ml 2 points 1 week ago (1 children)

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.

[–] gomp@lemmy.ml 1 points 1 week ago (2 children)

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)

[–] Atemu@lemmy.ml 1 points 1 day 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.

[–] flashgnash@lemm.ee 0 points 6 days ago (1 children)

Until someone rewrites git history and screws up your build

[–] Atemu@lemmy.ml 1 points 1 day ago

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