I had a hell of a time trying to get my first Tock program flashed after trying on NixOS and MacOS. Can I get approval to add some instructions into the shell.nix so people don't have to go on an Odyssey wondering why flashing isn't working successfully.

# If your board requires J-Link to flash, add these lines to your system wide configuration.

# Enable udev rules from jlink package
# services.udev.packages = [
#     pkgs.segger-jlink
# ];

# Add "segger-jlink" to your system packages and accept the EULA:
# nixpkgs.config.segger-jlink.acceptLicense = true;

I'm sorry to hear that you did not have a great experience getting started with Tock development on NixOS.

Can I get approval to add some instructions into the shell.nix

Sure, this seems like a good addition to me. I do want to emphasize that this is the required toolchain setup for one particular series of boards (which we happen to use as de-facto reference boards). Other boards will have their own toolchain requirements, which may be proprietary (in which case we don't want to blindly accept EULAs etc.) and/or require system-wide configuration changes (e.g. udev rules). More documentation seems strictly better though.

I simplified the shell.nix to use the rust-toolchain.toml when deciding what Rust targets and extensions are needed. In order to do this, I switched from the Mozilla Rust overlay to rust-overlay.

Regarding this change, I'm slightly skeptical. This is the first time I'm hearing of oxalica's Rust overlay. A nice property of all of the Nix infrastructure in Tock right now is that it is moderately self-contained, and only pulls in "official" sources (i.e. Nixpkgs & Mozilla's rust-overlay). As far as I can tell, this is just an improved version of Mozilla's overlay---in particular, the only benefit we'd get from it is removing the TOML parsing infrastructure from our own shell.nix. To me personally, that does not seem like a huge benefit. Are there any other benefits to using this overlay?

Using a non-"official" overlay brings trust and supply chain issues. What we should do, orthogonal to switching to a non-Mozilla overlay, is pin a specific revision and ensure that Tock's Nix closures do not pull in any non-pinned dependencies.

Thank you for the feedback. I had not considered the downstream effects of adding a dependency. I found that there is an official overlay provided by nix-community which I swapped to. I believe nix-community is official and is run by the same people as the whole Nixpkgs organization.

I believe nix-community is official and is run by the same people as the whole Nixpkgs organization.

While, to my knowledge, nix-community is orchestrated by a set of people that largely overlaps with Nixpkgs maintainers, its purpose is to be an incubator for projects that the main @NixOS organization does not want to explicitly & officially support. Take for example the Nix User Repository: https://github.com/nix-community/nur

At this point, I'm indifferent about switching. I don't see a huge benefit to using an alternative overlay, apart from outsourcing our 10s of lines of TOML parsing logic. The Mozilla overlay works(TM), and so why switch? I did skim over the fenix overlay, however, and its seems to be relatively lean, use an automatically generated manifest (great for reproducibility, bad if it ever were to lag behind upstream nightly releases). I don't want to stand in the way of progress, and so if this doesn't break anything I guess we might as well try this. If it doesn't work, we can always revert.

@alevy do you have any opinions on this?