Create a nix flake for reproducible development and build environments

[Irockasingranite]

This PR adds a nix flake definition, which provides as output a devshell, i.e. a development environment containing all necessary tools and libraries to work with bridle.

This (optionally) removes the dependency on any distribution packages installed via apt (or equivalent) apart from Nix itself, and removes the need for pip and virtualenv entirely.

To evaluate the flake, install Nix (the package manager), e.g. by apt install nix. Then either add experimental-features = nix-command flakes to ~/.config/nix/nix.conf, or add --experimental-features 'nix-command flakes' to any nix command.
After that, simply navigate to the bridle directory, and run nix develop to enter the devshell environment.

As a proof-of-concept, the PR also includes a subflake nix-workspace, which provides a fully fetched and initialized west workspace. This can be used to define derivations that include west commands, as demonstrated by the bridle-doc package also provided by the main flake. This makes it possible to generate the full documentation set by running nix build .#bridle-doc, also without installing any further dependencies or creating a local workspace.

This subflake is auto-generated via a python script, also currently located in nix-workspace. This script parses the project's west manifest and generates corresponding flake inputs, which can then be locked. Re-generating the subflake is only needed after manifest changes, otherwise upstream changes will be brought in via nix flake update as normal.

Note that the setup still suffers from an issue with subflakes, which requires building the required outputs from the subflake at least once to create a reference in the local nix store, before the main flake can reference it. In this case this means running nix build nix-workspace#workspace.

[tobiaskaestner]

I love this!!
Still, I want to raise two things.

1. Some chapter to the Bridle Getting Started Guide should really be added to walk users through setting up their workstation with nix

2. Abstracting away the system package dependencies that way is plain fantastic. Pinning down the zephyr pypi requirements is something different to me though. They are moving with the Zepyhr upstream and we need to make sure that these files are kept up to date. I do agree though that this is a blind spot in Zephyr upstream that as of today prevents reproducible builds with the upstream available tooling alone. Looking forward to discussing this further though.

[github-actions]

You can find the documentation preview for this PR at this link. It will be updated about 10 minutes after the documentation build succeeds.

Note: This comment is automatically posted by the Documentation Publishing GitHub Action.

[Irockasingranite]

I've reworked this a bit, hopefully making it simpler to use and to understand.

All python dependencies are now collected in nix/python-dependencies.nix. Since a handful of packages in there aren't in nixpkgs, I've added basic derivations for them, also all found under nix/. These then get appended to the upstream package set so no additional special treatment is necessary.

I've also used the get-flake flake to make importing the workspace subflake much easier (no more explicitly building the package before using it!).

Both nix/python-dependencies.nix and nix/workspace/flake.nix can be re-generated by running west nix-update, which will also update the workspace subflake inputs, to make sure nix and west see the same upstream revisions. By running this after west update, the two should stay in sync.

Finally I've added a section to the documentation on how to start using the flake, although without going into detail on the underlying principles of nix and flakes (that is better explained elsewere, anyway).

[Irockasingranite]

In light of west2nix now being available, which in combination with pyproject2nix solves all these problems much more elegantly, I have reworked the flake to use those instead.

This has made things much simpler, since python dependencies are resolved directly from the requirements.txt, and the workspace can simply be locked into a west2nix.toml file with a single command, with no additional code generation.

I've also moved the additionally packaged python dependencies into an external repository, so updating them won't require action in this one.

[rexut]

many, many thanks for all your efforts. I'm planning to merge this thread in until v3.6.0 release of Bridle on end of March '24.