fedimint: init at 0.3.2-rc.0 #316309
fedimint: init at 0.3.2-rc.0 #316309
Conversation
dpc
force-pushed
the
24-05-31-fedimintd-pkg
branch
3 times, most recently
from
30e3aff
to
37a45d0
Compare
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/prs-ready-for-review/3032/4046 |
pkgs/by-name/fe/fedimint/package.nix
Outdated
|
|
||
|
|
||
| # currently broken, will require some upstream fixes |
There was a problem hiding this comment.
| # currently broken, will require some upstream fixes | |
| # currently broken, will require some upstream fixes |
Everything or only partly?
There was a problem hiding this comment.
Small fix for a lack of HOME, but I need to find the time to verify. I'm also not sure how valuable is running our unit-tests in nixpkgs at all. We have a whole test suite with integration and e2e tests, and our unit-tests are comparatively low value in a grand scheme of things.
pkgs/by-name/fe/fedimint/package.nix
Outdated
|
|
||
| FEDIMINT_BUILD_FORCE_GIT_HASH = gitRev; | ||
|
|
||
| PROTOC = "${protobuf}/bin/protoc"; |
There was a problem hiding this comment.
| PROTOC = "${protobuf}/bin/protoc"; | |
| PROTOC = "${buildPackages.protobuf}/bin/protoc"; |
There was a problem hiding this comment.
I don't understand this one. Learning opportunity. Can you please explain or point me at something to read? @SuperSandro2000
There was a problem hiding this comment.
I don't know if there is any doc explaining cross in this detail but basically callPackage & mkDerivation together are splicing things into build, host and target architecture which might be equal or not. In this case we would get protobuf for the target arch (IIRC, basically the machine we are building the binary for to run) but we want the protoc that can run on the build machine.
| SystemConfiguration | ||
| ]; | ||
|
|
||
| outputs = [ "out" "fedimintCli" "fedimint" "gateway" "gatewayCli" "devimint" ]; |
There was a problem hiding this comment.
Isn't that overkill and just making things complicated?
There was a problem hiding this comment.
I'm not sure. These are relatively heavy (because Rust, and because these binaries include a logic-heavy Fedimint client library), and Fedimint is a distributed system with multiple actors with different roles. There are clients, there are distributed peers in a federation, there are gateways, there are binaries integrating gateways with other systems as plugins, there is a sandbox testing utility, etc.
Once I settled on multiple-outputs approach, it seemed relatively simple to just throw everything in into role-specific output. IIUC, whoever wants all binaries together can just use the default output.
pkgs/by-name/fe/fedimint/package.nix
Outdated
| cp -a $releaseDir/devimint $devimint/bin/ | ||
| ''; | ||
|
|
||
| FEDIMINT_BUILD_FORCE_GIT_HASH = gitRev; |
There was a problem hiding this comment.
We should just mock that to make things easier
There was a problem hiding this comment.
Our build system can detect it automatically, but only if git is available. If that's OK, I'll just add git to buildInputs
There was a problem hiding this comment.
Oh. Actually, it seems like the way this is downloaded, it's no longer git repository. OK. Will mock with 0oes.
dpc
force-pushed
the
24-05-31-fedimintd-pkg
branch
from
37a45d0
to
4d43bcd
Compare
dpc
force-pushed
the
24-05-31-fedimintd-pkg
branch
from
4d43bcd
to
bd36b3a
Compare
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/prs-already-reviewed/2617/1777 |
|
I promised a follow-up with NixOS module and I pushed it in #322815 |
Description of changes
Add Fedimint package.
Fedimint is a module based system for building federated applications. It is designed to be a trust-minimized, censorship-resistant, and private alternative to centralized applications.
Fedimint is sizeable Rust project (>90k lines of Rust), in a big workspace that shares most dependencies. Build creates multiple binaries, intended to run on a different systems (cli, daemon, LN gateway with cli and daemon, etc.), so to avoid rebuilding the project multiple times, I went with the multiple outputs route.
I'm one of the main contributors to Fedimint and maintain our Nix Flake based CI system, etc. so I'm planning to maintain this package. Once this is accepted, I'd like to follow up with NixOS modules that are already part of our flake.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.