`nuget-to-nix` fails only via `fetch-deps` on certain .NET project

[YoshiRulz]

Describe the bug

From #337548 (comment): Running nuget-to-nix the old manual way works for this project, but not via fetch-deps.

sample output when invoked as ./result

Steps To Reproduce

Steps to reproduce the behavior:

1. Checkout diadatp@24c7664 (packages https://github.com/AssetRipper/AssetRipper)
2. nix-build --pure -A assetripper.fetch-deps && ./result

Expected behavior

"Succesfully wrote lockfile to .../pkgs/by-name/as/assetripper/deps.nix"

Additional context

This seems to be a regression. At 0e5b1ff or e7fb591, it fails, but at 346e862 (e7fb591c9^) and earlier it succeeds. (If you copy the expression from the commit linked above, it will need changing slightly as it relies on newer features.)

Metadata

• system: "x86_64-linux"
• host os: Linux 6.6.32, NixOS, 24.05 (Uakari), 24.05beta403.67a8b308bae9
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.18.2
• channels(root): "nixos-24.05"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Notify maintainers

@corngood

---

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

---

Add a 👍 reaction to issues you find important.

[GGG-KILLER]

cc: @NixOS/dotnet

[GGG-KILLER]

Issue seems to be that they lack the nuget.org repo in their nuget.config so it isn't using the nuget.org repo.
Probably an issue in our setup (as by default that should be there unless there's a <clear/> at the start).

[corngood]

It probably just needs:

  preConfigureNuGet = ''
    # This should really be in the upstream nuget.config
    dotnet nuget add source https://api.nuget.org/v3/index.json \
      -n nuget.org --configfile nuget.config
  '';

Probably an issue in our setup (as by default that should be there unless there's a at the start).

This was done intentionally, under the assumption that a project shouldn't depend on the sources in the user's config.

[GGG-KILLER]

Probably an issue in our setup (as by default that should be there unless there's a at the start).

This was done intentionally, under the assumption that a project shouldn't depend on the sources in the user's config.

This is an assumption that is guaranteed by the SDK and works in pretty much every CI system though, I don't think it's good design if we're the only different ones.
If possible we should at least have a default file with the nuget.org repo if we don't want to have impurities from the user's home dir.

[corngood]

I guess the question is: is it a good idea for the upstream projects to include nuget.org in their config, if they use it?

If so, then it's easy enough to opt-in and then nudge upstream to add it. If there a good reason to instead defer to the user's config, then maybe we should consider adding it as a default.

[GGG-KILLER]

I'd say this is more about breaking users' expectations. If everyone else (including the SDK themselves) have the nuget.org repo by default, there's no reason for them to add it on their own config as it's redundant and we're the only ones that break that assurance.

The nuget.config file has an explicit mechanism for ignoring the globally configured repos which is the <clear/> line, without it, the expectation is that there'll at least be the nuget.org repo unless the users themselves do something to remove it from there.

[corngood]

I'm not against adding nuget.org, but I think we'd have to hard-code it. Currently, if a package has no nuget.config we init one with dotnet new nugetconfig, which does contain nuget.org. We'd need to also add the source if there's an existing config.

[GGG-KILLER]

I'm not against adding nuget.org, but I think we'd have to hard-code it. Currently, if a package has no nuget.config we init one with dotnet new nugetconfig, which does contain nuget.org. We'd need to also add the source if there's an existing config.

Doesn't the SDK combine the nuget.config in the project directory with configs in the home dir?
Couldn't we set up a home dir with the output of dotnet new nugetconfig and then have the SDK auto-merge them?

[corngood]

I think that might be tricky to do in a way that doesn't break configureNuget in a nix shell (when PATH is set). At least it seems more complicated than just adding the source.

[GGG-KILLER]

True, I guess we could perhaps do some checking to see if there's a <clear/> in the nuget.config and if there isn't, append a nuget.org repo entry to the start of the file, that should solve most problems.