Nix shell support for mac os x

[philipbeadle]

• I have added a summary of my changes to the changelog

DO NOT MERGE UNTIL DEVELOP FILTERING IS ON FOR COLD NIX BUILD

followup

i (dave) tried testing the nix shell on ubuntu/debian cold builds in docker, but there is a known issue where the root user in docker and nix don't play nice without some gnarly workarounds:

NixOS/nix#1559

looks like this can be addressed, but is out of scope here i think, and it doesn't stop real end-user-devs working with nix on ubuntu/debian because real devs won't be working as root

[thedavidmeister]

@philipbeadle well, this is me testing nix-shell on everything except windows

[pjkundert]

I have a Question (weird: I can't enter a lower-case 'Q' in this window); Once I build holochain-rust using nix-shell, am i forced to use the same nix-shell to build/test any other Holochain projects?

This seem to be because of the version checks done by NodeJS; if my system has a newer NodeJS (the one in nix-shell is Quite old vs. the one installed via brew), then the nodejs_conductor won't work if used under the newer system node when building/running unit tests; it doesn't seem to allow loading of the modules created by the older node. Or something (sorry, I didn't capture the exact errors before I rebuilt).

Anyway, this is something we'll need to document when detailing how to start/build a new Holochain project; if you build holochain-rust via nix-shell, you'll also need to build your new project using the same nix-shell used to build holochain-rust...?

[pjkundert]

EDIT: this was due to setting RUST_SODIUM_LIB_DIR=... and RUST_SODIUM_SHARED in my build environment, in order to get previous versions of holochain-rust to work on Debian. Running nix-shell --pure --run hc-test-app-spec (or unsetting the variables) works. Sorry!

---

Building on Debian fails due to not finding the libsodium.so.23, even though there are in fact 2
copies of libsodium.so.23 in /nix/store/...:

[nix-shell:~/src/holochain-rust]$ hc-test-app-spec
====================================================================================
RUNNING cargo test for zomes
------------------------------------------------------------------------------------
warning: profiles in config files require `-Z config-profile` command-line option
    Finished dev [unoptimized + debuginfo] target(s) in 0.15s
     Running zomes/blog/code/target/debug/deps/code-53811a43666ae4ab

running 4 tests
test blog::tests::check_sum_args_test ... ok
test post::tests::post_smoke_test ... ok
test blog::tests::post_entry_test ... ok
test post::tests::post_definition_test ... ok
...
====================================================================================
Running test.js in node
------------------------------------------------------------------------------------
npm WARN test No description
npm WARN test No repository field.
npm WARN test No license field.

audited 79 packages in 7.763s
found 0 vulnerabilities


> @ test /home/perry/src/holochain-rust/app_spec/test
> ./run.sh

module.js:682
  return process.dlopen(module, path._makeLong(filename));
                 ^

Error: libsodium.so.23: cannot open shared object file: No such file or directory
    at Object.Module._extensions..node (module.js:682:18)

[thedavidmeister]

@pjkundert glad --pure helped, see NixOS/nix#903 (comment) for more aggressive isolation

as far as node versions go, keeping consistent node versions across projects sounds like the problem to be solved, which nix may be one solution to

the ancient 8.x version that nix is shipping is due to trial and error over the past 6 months or so getting everything node related to work with core (usually neon related issues in the conductor), even minor/patch versions have broken things in the past, e.g. 8.14.0 worked while 8.4.0 and 8.14.2 broke at the cyprus workshop - minor typos were derailing the process, and this breakage/unpinning occurred while we were in transit :(

e.g. 8.x is still LTS until 2020 (https://nodejs.org/en/about/releases/) and IIRC using nvm to get the default 8.x version can break, or could break at some point, is maybe fixed now?

it's really hard to keep track of which versions of node even work at any point in time, and our CI infrastructure is not currently up to the task of throwing a matrix of node 8, 10, 11, 12 across debian, ubuntu, mac, nix, windows at all our tests (that would be about 20x new test runs)

without that CI infrastructure in place, we're being conservative about what we say we support and conservative about pinning/changing node versions in core

to me it would make sense to stick a minimal shell.nix file in each project that cares about node versions and pin those projects to a specific core release that uses the same, or a compatible, node version - that would be more ergonomic/reliable/lightweight than trying to dangle all your shell sessions off the core nix file

if we can safely upgrade to a newer node version and you think we should use that, let's get that in the nix shell and auto install scripts

note that we are pushing towards reducing/removing the need for a specific node versions in core through the future split of the holochain node conductor, and bringing more code back into native rust - the pain might just go away by itself over time, or at least be moved/quarantined to where it can be tackled in a dedicated node context/ecosystem