From ba2f31b6db0d71969bb1fcbeaed30925a935a5b0 Mon Sep 17 00:00:00 2001 From: zimbatm Date: Tue, 21 Jun 2022 15:37:15 +0200 Subject: [PATCH] buildDotnetModule: allow passing derivations to nugetDeps Sometimes I want to pass a different implementation of `mkNugetDeps`. For example in private repos, it can be handy to use `__noChroot = true` and bypass the deps.nix generation altogether. Or some Nuget packages ship with ELF binaries that need to be patched, and that's best done as soon as possible. --- doc/languages-frameworks/dotnet.section.md | 2 +- pkgs/build-support/dotnet/build-dotnet-module/default.nix | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/doc/languages-frameworks/dotnet.section.md b/doc/languages-frameworks/dotnet.section.md index f7af28a16775..408446674e90 100644 --- a/doc/languages-frameworks/dotnet.section.md +++ b/doc/languages-frameworks/dotnet.section.md @@ -72,7 +72,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` has to be 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. -* `nugetDeps` has to be used to specify the NuGet dependency file. Unfortunately, these cannot be deterministically fetched without a lockfile. A script to fetch these is available as `passthru.fetch-deps`. This file can also be generated manually using `nuget-to-nix` tool, which is available in nixpkgs. +* `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. For example, your project has a local dependency: diff --git a/pkgs/build-support/dotnet/build-dotnet-module/default.nix b/pkgs/build-support/dotnet/build-dotnet-module/default.nix index fa987237a75c..96e7596ed625 100644 --- a/pkgs/build-support/dotnet/build-dotnet-module/default.nix +++ b/pkgs/build-support/dotnet/build-dotnet-module/default.nix @@ -78,7 +78,9 @@ let then linkFarmFromDrvs "${name}-project-references" projectReferences else null; - _nugetDeps = mkNugetDeps { inherit name; nugetDeps = import nugetDeps; }; + _nugetDeps = if lib.isDerivation nugetDeps + then nugetDeps + else mkNugetDeps { inherit name; nugetDeps = import nugetDeps; }; nuget-source = mkNugetSource { name = "${name}-nuget-source";