search

holochain / n3h

nodejs implementation of holochain networking / p2p backend process
48 stars 7 forks source link

Node2nix #99

Open samrose opened 5 years ago

samrose commented 5 years ago

Introducing .nix files that build and package this repo for holoportos

samrose commented 5 years ago

FYI this built and passed tests at http://holoportbuild.holo.host/eval/774 and on remote updating machine in holoportos

neonphog commented 5 years ago

@samrose - would it be possible to put these files in a build/nix directory, or do they need to be in the root?

samrose commented 5 years ago

Because they are (partially) generated, and following the pattern of package.json/npm install, it tends to be way less complicated to have them arranged in the layout you see in the PR if that can work for you @neonphog ?

neonphog commented 5 years ago

@samrose - Yep, that's cool. Although, that brings up another question:

If they are partially generated, what are the rules / tooling for their regeneration. I.e. If we change the dependencies, how do they get updated? Typically in nodejs projects we make that a part of the npm test process, and fail CI if there are file differences after the run.

samrose commented 5 years ago

@neonphog the generated files portion cascades off from package.json, package-lock.json, and the extra node-packages.json that I had to add per the conventions of node2nix to get the placement of node-gyp-build where it needed to be in the nix process.

So, when you update package-lock.json, we will need some way to update the nix files by re-running node2nix with the required arguments on a build platform + scripting the overwriting of the output from that to rename a couple of files. I will probably do this manually for the short term based on your releases, and then we can script it for the long term in a build platform

anyone using nix/nixos could technically use these files as a "package" to install your code in a nix context now.

samrose commented 5 years ago

The tooling is https://github.com/svanderburg/node2nix

the build process I am using is: Due to nuances with node-gyp-build I am including https://github.com/samrose/n3h/blob/node2nix/node-packages.json as this is how node2nix deals with these native builders, by including them in a supplemental input. Then running

  1. node2nix -8 -i package.json -l ./package-lock.json --supplement-input node-packages.json
  2. Renaming the generated defualt.nix to n3h.nix, retaining the name of existing default.nix (probably temporary rename/restor to default.nix)
  3. rewrite line 13 of n3h.nix from inherit (pkgs) stdenv python2 utillinux runCommand writeTextFile; to inherit (pkgs) python2 utillinux runCommand writeTextFile; stdenv = pkgs.clangStdenv; (because gcc won't recognize -stdlib= flag that was being set by default by the build system)

that should be all it takes (as that is all I did)

we may be able to get the author of node2nix to let us

neonphog commented 5 years ago

https://github.com/holochain/n3h/pull/99/files#diff-71ee5f05fb17d0c4a599349588228ea5R884

@samrose - do you think this line ^^ means we have to follow the process you just mentioned every time the n3h version is updated?

samrose commented 5 years ago

"@samrose - do you think this line ^^ means we have to follow the process you just mentioned every time the n3h version is updated?"

@neonphog My proposal is that we update this each time you create a release

neonphog commented 5 years ago

@samrose - let me know what you think - https://github.com/samrose/n3h/pull/1

we can run this manually for now, but it should be fairly straight forward to add to the CI system if we should desire.