substrate-node-template icon indicating copy to clipboard operation
substrate-node-template copied to clipboard

Update nix support

Open ink-pot-monkey opened this issue 2 years ago • 5 comments

cargo build --release currently fails if the user is relying on the nix shell provided with the error:

error[E0658]: use of unstable library feature 'proc_macro_is_available'
  --> /home/thomassdk/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-1.0.36/src/detection.rs:28:21
   |
28 |     let available = proc_macro::is_available();
   |                     ^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #71436 <https://github.com/rust-lang/rust/issues/71436> for more information
   = help: add `#![feature(proc_macro_is_available)]` to the crate attributes to enable

For more information about this error, try `rustc --explain E0658`.
error: could not compile `proc-macro2` due to previous error
warning: build failed, waiting for other jobs to finish...
error: build failed

This pull request fixes this by updating the Nix support to use flakes

ink-pot-monkey avatar Apr 28 '22 18:04 ink-pot-monkey

Thanks for this! I have not reviewed, but this should match as much as possible the config in substrate that should be up to date: https://github.com/paritytech/substrate/tree/master/bin/node-template

nuke-web3 avatar Apr 29 '22 00:04 nuke-web3

Hi @NukeManDan this now matches exactly that config you linked (aside from updating the release of the rust toolchain as this was breaking the build for me)

The pinning is being done via the flakes mechanism and contained in the flake.lock file which now set to 1.62.0-nightly which successfully runs the cargo build.

To update the locked version its a easy as running nix flake update in the repo and committing the new lock file

ink-pot-monkey avatar May 03 '22 13:05 ink-pot-monkey

LGTM as a non nix user. Asking the nix pros here at parity I got:

but do note that flake hasn't entered stable Nix yet. So you'll want to add docs about enabling the Nix experimental flags as well. There's also the thing that right now the default Nix on NixOS is still 2.3. Some users have refused to upgrade to 2.4 for now (because it brings some issues, mostly backward incompatibility). Flake is only available (as experimental) from 2.4 onwards.

I suppose this is an opinionated update, as you need experimental tools that might not work for all nix users. You think this is required over the existing nix usage upstream?

nuke-web3 avatar May 03 '22 22:05 nuke-web3

but do note that flake hasn't entered stable Nix yet. So you'll want to add docs about enabling the Nix experimental flags as well. There's also the thing that right now the default Nix on NixOS is still 2.3. Some users have refused to upgrade to 2.4 for now (because it brings some issues, mostly backward incompatibility). Flake is only available (as experimental) from 2.4 onwards.

I suppose this is an opinionated update, as you need experimental tools that might not work for all nix users. You think this is required over the existing nix usage upstream?

Since the default is to not use flakes, It'd be a nicer experience for people trying out nix to keep a working shell.nix.

It would be possible to compromise, and retain a shell.nix which non-flake nix users could still use nix-shell, but the flake.nix could use the shell.nix. The shell.nix could take pkgs as an argument, with a default value of a pinned nixpkgs overlaid with whatever rust overlay, and otherwise factor out the mkShell { ... } in the flake.nix.

Some downsides to this: I'd think the .envrc would need to figure out whether to use the nix flake or the nix-shell, and you'd have to worry about updating the inputs for both the flake (easy) and pinned values in the shell.nix (for non-flake users).

rgoulter avatar May 04 '22 02:05 rgoulter

Having learnt Nix only since the advent of flakes I did not appreciate the extent to which flakes have split the community, it was always sold to me as the "golden future" of nix. The maintainers are also heavily leaning towards making flakes the mainstream way of interacting with Nix projects so while it is more experimental it also has the benefit of being tentatively "future" proof.

I've done a bit of digging however and come up with a compromise that uses the flake to provide a backwards compatible shell.nix output. The .envrc file keeps checking for lorri and falling back to nix if not there but with an initial extra check for flakes

ink-pot-monkey avatar May 04 '22 09:05 ink-pot-monkey

Seems we have an approval from a core eng. on this PR - @thomassdk this isn't the place to land it though. If you still want it, please do open up one upstream? :pray: https://github.com/paritytech/substrate/blob/master/bin/node-template/shell.nix Happy to get @-ed there to help get it approved.

nuke-web3 avatar Nov 22 '22 01:11 nuke-web3