buildDotnetModule buildInputs depend on dotnet runtime packages for every possible platform

gbtb commented 3 weeks ago

Describe the bug

Hello :wave: This line makes buildDotnetModule include every package from SDK runtime-collection into build-time closure. Basically, each time I want to tweak or update existing dotnet package, nix-build floods my terminal with a download list of stuff for platforms like macOS, win32, musl-linux and what not, even though I only care about linux-x64 platform.

I wonder what's a motivation behind this unconditional dependence? For one particular package I'm working on right now, removal of sdk runtime packages doesn't make a difference, it builds just fine. Probably that's because its deps.nix was already containing reference to Microsoft.NETCore.App.Runtime.linux-x64 . Searching for the 'Microsoft.NETCore.App.Runtime.linux-x64' inside nixpkgs also reveals several packages whose deps.nix contain explicit ref to a runtime. I wonder, maybe we can remove this runtime-collection from buildInputs altogether or hide it behind some flag?

Steps To Reproduce

Steps to reproduce the behavior:

Try to tweak any dotnet-based package in nixpkgs

Expected behavior

nix-build should only download dotnet runtime packages for platforms that I build my dotnet package for.

Notify maintainers

@NixOS/dotnet

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

- system: `"x86_64-linux"`
 - host os: `Linux 6.8.12, NixOS, 24.11 (Vicuna), 24.11pre657537.5ad6a14c6bf0`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.5`
 - channels(root): `"home-manager, master.tar.gz, nixos"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Add a :+1: reaction to issues you find important.

corngood commented 3 weeks ago

This is something that's on my radar. Currently the package set is meant to be 'everything that can be implicitly referenced from the SDK'. That can be useful, since it's possible to cross-target other RIDs, but is overkill in a lot of situations.

Fixing this should also help integrate the souce-built SDK, because we can pull in binary packages for cross targeting.

Ideally I'd like to solve this for both SDK packages and nugetDeps at the same time.

I wonder what's a motivation behind this unconditional dependence?

This is described in update.sh

    # Moving them to a separate list stored alongside the SDK package definitions,
    # and implicitly including them along in buildDotnetModule allows us
    # to make updating .NET SDK packages a lot easier - we now just update
    # the versions of these packages in one place, and all packages that
    # use buildDotnetModule continue building with the new .NET version without changes.

For one particular package I'm working on right now, removal of sdk runtime packages doesn't make a difference, it builds just fine. Probably that's because its deps.nix was already containing reference to Microsoft.NETCore.App.Runtime.linux-x64 . Searching for the 'Microsoft.NETCore.App.Runtime.linux-x64' inside nixpkgs also reveals several packages whose deps.nix contain explicit ref to a runtime.

These explicit references are also bad, for the same reason.

YoshiRulz commented 4 days ago

I believe this is the same issue I brought up in https://github.com/NixOS/nixpkgs/issues/179136#issuecomment-1640196706, where I also suggested unsafeDiscardStringContext, and the response was that it was impossible to fix.

NixOS / nixpkgs