buildDotnetModule: move nugetDeps throw to when its actually needed

Previously we had an assert that would complain when nugetDeps wasnt set,
which also didnt allow any passthru attributes (like fetch-deps) to be
build. That causes a cycle where you need nugetDeps to fetch the nuget
deps, but arent able to build the script to do so.

2 files changed, 12 insertions, 14 deletions

diff --git a/doc/languages-frameworks/dotnet.section.md b/doc/languages-frameworks/dotnet.section.md
index 0927ce9146f91..1baa135ae5866 100644
--- a/doc/languages-frameworks/dotnet.section.md
+++ b/doc/languages-frameworks/dotnet.section.md
@@ -71,7 +71,7 @@ The `dotnetCorePackages.sdk` contains both a runtime and the full sdk of a given
 
 To package Dotnet applications, you can use `buildDotnetModule`. This has similar arguments to `stdenv.mkDerivation`, with the following additions:
 
-* `projectFile` is used for specifying the dotnet project file relative to the source root. These usually have `.sln` or `.csproj` file extensions. This can be an array of multiple projects as well.
+* `projectFile` is used for specifying the dotnet project file, relative to the source root. These usually have `.sln` or `.csproj` file extensions. This can be a list of multiple projects as well. Most of the time dotnet can figure this location out by itself, so this should only be set if necessary.
 * `nugetDeps` takes either a path to a `deps.nix` file, or a derivation. The `deps.nix` file can be generated using the script attached to `passthru.fetch-deps`. This file can also be generated manually using `nuget-to-nix` tool, which is available in nixpkgs. If the argument is a derivation, it will be used directly and assume it has the same output as `mkNugetDeps`.
 * `packNupkg` is used to pack project as a `nupkg`, and installs it to `$out/share`. If set to `true`, the derivation can be used as a dependency for another dotnet project by adding it to `projectReferences`.
 * `projectReferences` can be used to resolve `ProjectReference` project items. Referenced projects can be packed with `buildDotnetModule` by setting the `packNupkg = true` attribute and passing a list of derivations to `projectReferences`. Since we are sharing referenced projects as NuGets they must be added to csproj/fsproj files as `PackageReference` as well.
@@ -100,7 +100,7 @@ To package Dotnet applications, you can use `buildDotnetModule`. This has simila
 * `dotnetPackFlags` can be used to pass flags to `dotnet pack`. Used only if `packNupkg` is set to `true`.
 * `dotnetFlags` can be used to pass flags to all of the above phases.
 
-When packaging a new application, you need to fetch it's dependencies. You can set `nugetDeps` to an empty string to make the derivation temporarily evaluate, and then run `nix-build -A package.passthru.fetch-deps` to generate it's dependency fetching script. After running the script, you should have the location of the generated lockfile printed to the console. This can be copied to a stable directory. Note that if either `projectFile` or `nugetDeps` are unset, this script cannot be generated!
+When packaging a new application, you need to fetch its dependencies. You can run `nix-build -A package.fetch-deps` to generate a script that will build a lockfile for you. After running the script you should have the location of the generated lockfile printed to the console, which can be copied to a stable directory. Then set `nugetDeps = ./deps.nix` and you're ready to build the derivation.
 
 Here is an example `default.nix`, using some of the previously discussed arguments:
 ```nix
diff --git a/pkgs/build-support/dotnet/build-dotnet-module/default.nix b/pkgs/build-support/dotnet/build-dotnet-module/default.nix
index 569ad2615e67c..41f3271f10cc1 100644
--- a/pkgs/build-support/dotnet/build-dotnet-module/default.nix
+++ b/pkgs/build-support/dotnet/build-dotnet-module/default.nix
@@ -82,10 +82,6 @@
 , ...
 } @ args:
 
-# TODO: Automatically generate a dependency file when a lockfile is present.
-# This file is unfortunately almost never present, as Microsoft recommands not to push this in upstream repositories.
-assert nugetDeps == null -> throw "Defining the `nugetDeps` attribute is required, as to lock the NuGet dependencies. This file can be generated by running the `passthru.fetch-deps` script.";
-
 let
   inherit (callPackage ./hooks {
     inherit dotnet-sdk dotnet-test-sdk disabledTests nuget-source dotnet-runtime runtimeDeps buildType;
@@ -97,12 +93,14 @@ let
     else null;
 
   _nugetDeps =
-    if lib.isDerivation nugetDeps
-    then nugetDeps
-    else mkNugetDeps { inherit name; nugetDeps = import nugetDeps; };
+    if (nugetDeps != null) then
+      if lib.isDerivation nugetDeps
+      then nugetDeps
+      else mkNugetDeps { inherit name; nugetDeps = import nugetDeps; }
+    else throw "Defining the `nugetDeps` attribute is required, as to lock the NuGet dependencies. This file can be generated by running the `passthru.fetch-deps` script.";
 
   # contains the actual package dependencies
-  _dependenciesSource = mkNugetSource {
+  dependenciesSource = mkNugetSource {
     name = "${name}-dependencies-source";
     description = "A Nuget source with the dependencies for ${name}";
     deps = [ _nugetDeps ] ++ lib.optional (localDeps != null) localDeps;
@@ -111,19 +109,19 @@ let
   # this contains all the nuget packages that are implictly referenced by the dotnet
   # build system. having them as separate deps allows us to avoid having to regenerate
   # a packages dependencies when the dotnet-sdk version changes
-  _sdkDeps = mkNugetDeps {
+  sdkDeps = mkNugetDeps {
     name = "dotnet-sdk-${dotnet-sdk.version}-deps";
     nugetDeps = dotnet-sdk.passthru.packages;
   };
 
-  _sdkSource = mkNugetSource {
+  sdkSource = mkNugetSource {
     name = "dotnet-sdk-${dotnet-sdk.version}-source";
-    deps = [ _sdkDeps ];
+    deps = [ sdkDeps ];
   };
 
   nuget-source = symlinkJoin {
     name = "${name}-nuget-source";
-    paths = [ _dependenciesSource _sdkSource ];
+    paths = [ dependenciesSource sdkSource ];
   };
 in
 stdenvNoCC.mkDerivation (args // {