nuget-to-nix: Generated file not formatted

[UlyssesZh]

Describe the bug

The file generated by nuget-to-nix is not formatted. This leads to an error when a generated file is included in a PR and checked by the nixfmt-check step in GitHub Actions.

Some of the ideas that people proposed:

• Modify nuget-to-nix to make the generated file formatted;
• Exempt generated files from nixfmt-check;
• Generate JSON (or alike) instead of Nix.

For details of the pros and cons of those approaches, read the discussions below here and in #325053.

For people who are packaging dotnet applications and meet with nixfmt-check failing: before a long-term solution is decided, temporarily we just merge PR with the check failing anyway (#360598 (comment)). There is no need to run nixfmt in the updater script.

Notify maintainers

@NixOS/dotnet

---

Note for maintainers: Please tag this issue in your PR.

---

Add a 👍 reaction to issues you find important.

[TomaSajt]

Related discussion at: #325053

[GGG-KILLER]

@corngood any apprehensions about converting the output of fetch-deps to JSON?
Iirc we don't have anything that's actually dynamic in it so it should be a 1:1 conversion.
I plan to do it if you give the ok.

About the points you were worried about:

1. Mirror support: we could have an array of urls where we can get the package from instead of a single URL.

2. RIDs could be added as an attribute and we filter through their value (or absence) when building.

[corngood]

I just think it's the wrong way to fix the nixfmt-check problem. JSON might be the right tool for the job, but that's not really why we're choosing it. We're choosing it because it's not checked. If someone decides to add json formatting and checks, we'll be right back in the same place.

I think it would be better to just make fetch-deps format the files. Some packages already do this in their update scripts.

[GGG-KILLER]

I just think it's the wrong way to fix the nixfmt-check problem. JSON might be the right tool for the job, but that's not really why we're choosing it. We're choosing it because it's not checked. If someone decides to add json formatting and checks, we'll be right back in the same place.

I think it would be better to just make fetch-deps format the files. Some packages already do this in their update scripts.

The thing is that we're generating nix code without even needing it, all of our data is completely static and doesn't actually need to be nix, it's pretty much a data file the same way the SDK info files are JSON.

The standard for lockfile generation is to use whatever the language uses, or in the absence of it, JSON or YAML afaik.
We're literally generating a lockfile but in nix without needing it, we don't use any of the nix features or anything that actually requires us to output code instead of plain data.
I'd say it's more about fixing a wrong choice instead of carrying on with it.

[MattSturgeon]

JSON might be the right tool for the job, but that's not really why we're choosing it.

I don't see "avoiding formatting" as the reason to choose JSON.

I see auto-formatting as the prompt to have this discussion in the first place; but the reason to choose JSON is that it is a more appropriate language.

Even if JSON was also going to be auto-formatted, it would still be the better language. However, as things stand now there is little motivation to have data files auto-formatted, so hopefully that's a non-issue.

[corngood]

I just don't really see what we gain from switching. We'll have to break things and/or deal with compatibility.

Performance is a potential benefit, but I haven't benchmarked it, and the only discussion I can find about it is here: https://discourse.nixos.org/t/parser-performance-json-vs-nix/20237/3

[GGG-KILLER]

I just don't really see what we gain from switching. We'll have to break things and/or deal with compatibility.

What we gain is using the right tool for the job, data is not meant to be stored as code.
Lockfiles are data and therefore shouldn't be code files.

That's my stance on it at least. In practice we don't actually gain anything, but keeping it like this just because of sunken cost while other nixpkgs builders were either correct from the start or have fixed this already feels like we are falling for the sunken cost fallacy.

[UlyssesZh]

I read the discussions on this topic and updated the issue description with some summary of the discussions for people who may land on this issue in the future.

[corngood]

In #361579 I have a change to run nixfmt by default after nuget-to-nix. i.e.

Modify nuget-to-nix to make the generated file formatted;

I know there are objections to that doing that, but to me the most pressing problem is described above:

For people who are packaging dotnet applications and meet with nixfmt-check failing: before a long-term solution is decided, temporarily we just merge PR with the check failing anyway (#360598 (comment)). There is no need to run nixfmt in the updater script.

It's tedious having to dig through the check logs to make sure it's only failing on a deps file.

I would still prefer "Exempt generated files from nixfmt-check" as a short term solution, but that doesn't seem to be going anywhere.

I'm also not strongly against the idea of "Generate JSON (or alike) instead of Nix", but I don't see a simple way to do it without breaking compatibility, or maintaining some ugly hacks.