cafkafk/nixpkgs
cafkafk/nixpkgs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

buildDotnetModule: move nugetDeps throw to when its actually needed

Browse source 
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.
This commit is contained in:
Ivar Scholten 2022-09-09 01:01:14 +02:00
parent 03a1b62cb3
commit 8e00d6ac26
No known key found for this signature in database
GPG key ID: E22887AD87C33E3C
2 changed files with 12 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
doc/languages-frameworks/dotnet.section.md
View file

@ -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

22
pkgs/build-support/dotnet/build-dotnet-module/default.nix
View file

@ -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 // {