nix: add a native devShell flake

[willcl-ark]

Add a native nix devShell flake and .envrc to the project.

Previous

As I understand it this fork aims to have a seperate packaging repo, and I think that is a good thing.

That said, I do think there is still scope to include a minimal nix flake here, both for developement and regular builders.

This PR demonstrates adding such a first-party Nix flake, providing both a development shell and a buildable package right from the checked-out source tree.

Pros

The goal is to make the common development path simple:

git clone <repo>
cd bitcoin
nix develop   # develop
nix build .   # build

This is intentionally useful both for development, not only packaging. A contributor can switch branches, test local changes, and build the exact checkout without needing a separate packaging repository or ad hoc override setup (like a flake placed in another directory).

Keeping a minimal flake in-tree means the source, build options, dependencies, and development environment can evolve together. When CMake options or dependency requirements change, the flake can be updated in the same PR that makes the source change, and CI can catch breakage immediately.

It also improves contributor ergonomics. nix develop gives a dev environment, while nix build . builds the current source. This is much simpler than cloning a second packaging repository, updating source pins, or using override-input workflows for local branches, IMO.

This does not prevent external packaging repositories from existing though. Downstream packaging can consume this flake directly via:

bitcoin.packages.${system}.default

or through the exported overlay:

overlays = [ bitcoin.overlays.default ];

That lets downstream packaging repos keep their own release policy, binary caches, deployment modules, hardening choices, and package overrides while reusing the first-party build expression as a base.

The package is designed to remain override-friendly. Common build choices are exposed as package arguments, for example:

bitcoin-core.override {
  withTests = false;
  withBench = true;
}

and the source can be replaced with:

bitcoin-core.override {
  source = mySource;
}

Cons

A first-party flake does add maintenance surface to the source repository. Build option changes may need corresponding Nix updates, and reviewers need to be willing to consider small packaging changes alongside source changes.

Interface and configuration choices

A separate packaging repository will still be better for release-specific policy, binary cache management, deployment modules, downstream patches etc.

The intended split here is that this repository provides a minimal, first-party development and build interface, while downstream packaging remains free to consume, override, or ignore it depending on its own goals.

The flake exports:

• packages.${system}.default
• packages.${system}.bitcoin-core
• devShells.${system}.default
• overlays.default

Supported systems are currently:

• x86_64-linux
• aarch64-linux
• aarch64-darwin

Also included is a .envrc do use the flake automagically via direnv, which IMO is the "first party nix experience". Just my two cents.

[willcl-ark]

To be -clear, this is draft and RFC as it's intended at this time only to spark discussion :)

[josibake]

Nice, thanks for opening this! From a design standpoint, the only issue I have with this is the use of the word both. I do think there is value to having a developer flake.nix in the root of the repo, but that's as far as I would go. Everything in that flake should be geared towards easy of development, e.g., fetching and easily swapping out dependencies, nice aliases in a devshell, opinionated defaults for the compiler, ccache config, etc.

Packing should be owned in a separate repo, where the that flake is strictly focused on packaging a release, and easily supporting users overrides (e.g., source, dependencies). It could also have a nix module for deployment.

I have toy project for demonstrating exactly this: https://github.com/josibake/champix/. If you end up taking a look, I'd be keen to know which parts from your packaging you would port over there!

Also, if you're willing to split this out into just a development flake for this PR, I'd be more than happy to merge.

[willcl-ark]

Now split into what I think is a clean devShell :)

[janb84]

Would it not create a "lot of" churn to include this ? (I get having stable versions is also nice)

[josibake]

I'd argue flake.lock is essential for devshells. AFAIU, the lock file is used for the cache, so faster builds, and without the lockfile you're likely to unexpectedly pull in new versions of dependencies (without intending to), which you absolutely don't want while developing.

[josibake]

ACK, thanks for adding, @willcl-ark !