dotnet: nixfmt output of nuget-to-nix

[corngood]

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[corngood]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 361579

---

x86_64-linux

✅ 5 packages built:

• dotnet-outdated
• juniper
• netcoredbg
• tagger
• yafc-ce

[MattSturgeon]

Related discussion:

• treewide: format files generated by nuget-to-nix with nixfmt and make code generation of nuget-to-nix follow nixfmt rules #325053
• nuget-to-nix: Generated file not formatted #358025

[MattSturgeon]

No issues from me. I think JSON lockfiles will be better in the long term, but I'm fine with this too.

I also believe concerns raised by others would be reassured if this is treated as a stopgap solution?

[MattSturgeon]

Not really relevant to this PR, but rather than substituting these in, would it make sense to instead set PATH using lib.makeBinPath [ nuget-to-nix nixfmt-rfc-style ]?

[corngood]

We could also do this with or without actually updating the lockfiles. I have them in here now, which was useful to check the rebuild count, etc.

[corngood]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 361579

---

x86_64-linux

✅ 5 packages built:

• dotnet-outdated
• juniper
• netcoredbg
• scarab
• yafc-ce

[MattSturgeon]

We could also do this with or without actually updating the lockfiles. I have them in here now, which was useful to check the rebuild count, etc.

I think my preference would be not to do a treewide reformat yet. CI only requires formatting for new files (and already compliant files).

The nixpkgs-review build with the reformat is reassuring either way.

Depending on timing, there's a chance a JSON-based solution may be ready before many of these packages end up bumping their lockfiles.

Not that this is important either way. I have no objection to a reformat now.

[corngood]

I think my preference would be not to do a treewide reformat yet. CI only requires formatting for new files (and already compliant files).

Done. I don't think there's really a good argument for regenerating, other than to prove that it can be done.

[nixpkgs-ci]

Successfully created backport PR for release-24.11:

• [Backport release-24.11] dotnet: nixfmt output of nuget-to-nix #362190