Please name commit in a proper way following our CONTRIBUTING.md.

done

cc @obadz

My suggestions:

• Use fetchNuGet for all these things that you are unziping straight out of nuget
• Use buildDotnetPackage for those things that you are building yourself
• Prefer building from source rather than getting binary from Nuget when possible
• Put all these derivations in pkgs/top-level/dotnet-packages.nix

(Some like Json and F# Compiler Services are already there btw)

• Use fetchNuGet for all these things that you are unziping straight out of nuget

OK, makes sense.

• Use buildDotnetPackage for those things that you are building yourself

I have to see how/if its possible to work with buildDotNetPackage. I takes a different approach, but that might not be a big problem.

• Prefer building from source rather than getting binary from Nuget when possible

This is going to be very hard to automate, because of how the .NET ecosystem practically works. A lot of manual work is required to do this. It may be an approach to take for packaging this tool, but will be a big impediment for people who just want to get work done. The purpose of this tool is to make life as simple as possible to people starting out with .NET on Nix(OS) by automating the tedious parts.

• Put all these derivations in pkgs/top-level/dotnet-packages.nix

I chose to put this in the tools directory, because that is where cabal2nix lives as well. This distinction seems to be useful, no?

(Some like Json and F# Compiler Services are already there btw)

Yes. But not necessarily in the right version. If I update them it might break other packages depending on the current one, right?

I don't mean that paket2nix should produce a derivation that builds from source, I meant that those derivations that end up in pkgs/top-level/dotnet-packages.nix should be preferrably built from source, but if it's easier to include some binaries that's probably acceptable too.

Re exact location of tiles, I'll let @lethalman opine. He liked having it all in one file.

Feel free to upgrade anything in dotnet packages. If an upgrade breaks a dependent package, then we'll have to create a pinned version of the required library, but until then the default assumption is that we can use the latest stable version for everything.

I don't mean that paket2nix should produce a derivation that builds from source, I meant that those derivations that end up in pkgs/top-level/dotnet-packages.nix should be preferrably built from source, but if it's easier to include some binaries that's probably acceptable too.

Right, I had a feeling the two aspects got somewhat mixed up :) I agree, that approach generally makes sense!

Re exact location of tiles, I'll let @lethalman opine. He liked having it all in one file.

Do you mean with respect to future packages or paket2nix itself? (My guess is the latter)

Feel free to upgrade anything in dotnet packages. If an upgrade breaks a dependent package, then we'll have to create a pinned version of the required library, but until then the default assumption is that we can use the latest stable version for everything.

Fair enough. Its all not exactly ideal yet, but at least workable.

Thx for your feedback!

I'd like to suggest that you put the version information of the packages you add into an extra variable, so updates become more simple.

For example, you have:

#...
name = "foo-1.2.3"
src = fetchurl { url = ".../foo/1.2.3..."; # ...

but better would be

version = "1.2.3";
name = "foo-${version}"
src = fetchurl { url = ".../foo/${version}..."; # ...

(triage) @krgn any update?

It would be good to polish this tool and get it into nix. However, I'm a bit unsure how to proceed. I will heed @matthiasbeyer's advice and make those changes, and I'll also dig a bit more into the nuget API to find out what can be further automated (initial sense is that its all build artifacts, so no source links, but feasible nonetheless).

@krgn, I would suggest looking at dotnet-packages.nix, which already contains some of the packages that are in your PR. Instead of reincluding them in a different format, I would suggest adding the ones that you are missing, building from source when possible, from Nuget when not.

I am not working on it any longer, so this PR can be closed.