nixify

[plebhash]

allows building on a nix-shell environment.

the nakamoto-wallet crate needs libusb-1.0.

now this is possible:

$ nix-shell
# cargo build -p nakamoto-wallet            # libusb-1.0 will be found

[vincenzopalazzo]

This is wrong and will work only on your system.

You are missing also rustup

[plebhash]

sorry @vincenzopalazzo you are correct, I have rust on my home-manager setup and that contaminated the development environment where I validated this shell.nix

I'm pushing a commit that adds rustup to the buildInputs of pkgs.mkShell: 6161221

I created a lxc container running nixOS for a clean test environment, and the nix-shell allows for building correctly when I try to build nakamoto-wallet inside of it.

Is there anything else you feel needs improvement on this shell.nix?

[vincenzopalazzo]

Is there anything else you feel needs improvement on this shell.nix?

not from my hand, I need to test it on my NixOS build machine and I will be back to you.

Usually, I put this nix stuff under a nix or .nix directory to make it optional

[plebhash]

Usually, I put this nix stuff under a nix or .nix directory to make it optional

ack, done

[vincenzopalazzo]

LGTM

Can you squash the commit in a single one and change the commit
header to [meta] add nix-shell script for a dev env or something like that.

Maybe @cloudhead has a better idea for the commit header 😄

[plebhash]

@vincenzopalazzo apologies for bringing this up again, but I wonder if having the *.nix files on the repository root dir is really that undesirable?

@realeinherjar helped me start working on a new flake.nix

It's still WIP but leveraging flakes should open up a few more possibilities, not only for a nixified development workflow (like this PR is enabling) but also for a nixified user experience.

Users could run nix run github:cloudhead/nakamoto and get nakamoto working out of the box. But in order for that to be possible, flake.nix needs to live in the repo root dir, so that's why I'm revisiting this topic.

Depending on feedback, I would probably close this PR in favor of a new one to keep things organised, while also making sure to have the commit history following the pointers from your last comment.

[vincenzopalazzo]

Nix flake is completely another world, in GCC or another project that I am involved with nix they prefer to have a .nix/flake.nix and then if I want to use nix flake I do cp .nix/flake.nix .

However, Nix Flake is unrelated to my previous suggestion, and I think it is also a little bit of overkill for Nakamoto. Other than the wallet (that it is not well integrated out of the box with ColdCard) nakamoto is run as a library not as a node due to that we do not have RPC API to do anything useful except syncing with the network.

However, this is not up to me to decide.

I think The Last World is from @cloudhead not from me so please do not feel discouraged

[realeinherjar]

have a .nix/flake.nix and then if I want to use nix flake I do cp .nix/flake.nix .

Yes, but can I do a nix run github:cloudhead/nakamoto -p nakamoto-node -- --testnet if the flake.nix is not on the root dir?
Because that would be really helpful.
Imagine pairing that with nixos-anywhere.

I don't think this PR scope should cover only

allows building on a nix-shell environment.

[vincenzopalazzo]

Yes, but can I do a nix run github:cloudhead/nakamoto -p nakamoto-node -- --testnet if the flake.nix is not on the root dir?

it is just a matter of preference, as I said in my message that you did not quote "they prefer to have a ..."

I really did not care if I can do nix run github:cloudhead/nakamoto -p nakamoto-node -- --testnet or cp .nix/flake.nix . && nix run github:cloudhead/nakamoto -p nakamoto-node -- --testnet. I am interested in the p2p area of nakamoto

[plebhash]

nix run github:cloudhead/nakamoto -p nakamoto-node -- --testnet or cp .nix/flake.nix . && nix run github:cloudhead/nakamoto -p nakamoto-node -- --testnet

sorry @vincenzopalazzo maybe I wasn't clear on my original explanation

the user would be able to do nix run github:cloudhead/nakamoto -p nakamoto-node -- --testnet without ever cloning the repo (assuming flakes.nix lives in the repo root)... that's why I tried to frame it as a nixfication for a user experience, rather than just a development experience

I believe your point about the project aiming to be nothing but a library and the node not exposing any RPCs is still a counterargument to this, but I thought I should clarify anyway

[vincenzopalazzo]

the user would be able to do nix run github:cloudhead/nakamoto -p nakamoto-node -- --testnet without ever cloning the repo

Ah nice! I did not know of this usage of nix flakes!

I believe your point about the project aiming to be nothing but a library and the node not exposing any RPCs is still a counterargument to this, but I thought I should clarify anyway

I did not say that is the aim of the project, I pointed out the state of the art!

[realeinherjar]

Ah nice! I did not know of this usage of nix flakes!

Yes, sorry I though that was understood in my example

[plebhash]

I did not say that is the aim of the project, I pointed out the state of the art!

well that's cool! has there ever been a discussion about exposing RPCs from nakamoto-node?

cc @a-moreira

[vincenzopalazzo]

well that's cool! has there ever been a discussion about exposing RPCs from nakamoto-node?

I have a branch somewhere that expose a UNIX socket, but I am not actively working on it