| 4 Dec 2024 |
 Corngood | * ~~nothing. they're the same package~~ | 19:34:00 |
| Corngood | * nothing. they're the same package | 19:34:40 |
 lostmsu | Still getting confused
I have the following two system packages installed + Rider:
dotnetCorePackages.dotnet_8.aspnetcore
dotnet-sdk_9
and yet I get
$ dotnet --info
Host:
Version: 8.0.11
Architecture: x64
Commit: 9cb3b725e3
RID: linux-x64
.NET SDKs installed:
No SDKs were found.
.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.11 [/nix/store/pyh7d87igawxpr9qnpc0ap4v0irx3591-dotnet-aspnetcore-runtime-8.0.11/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.11 [/nix/store/pyh7d87igawxpr9qnpc0ap4v0irx3591-dotnet-aspnetcore-runtime-8.0.11/share/dotnet/shared/Microsoft.NETCore.App]
Other architectures found:
None
Environment variables:
Not set
global.json file:
Not found
Learn more:
https://aka.ms/dotnet/info
Download .NET:
https://aka.ms/dotnet/download
$ which dotnet
/run/current-system/sw/bin/dotnet | 19:56:41 |
| Corngood | Check this out: https://nixos.org/manual/nixpkgs/stable/#using-many-sdks-in-a-workflow
You need to combine them into a single package because the dotnet CLI has no mechanism for finding things unless they are all in one DOTNET_ROOT.
| 20:18:12 |
| lostmsu | What about global environment? | 20:19:12 |
| Corngood | you can install the output of combinePackages wherever you're using e.g. dotnet-sdk_9 | 20:19:58 |
|  GGG joined the room. | 21:44:23 |
| GGG changed their display name from GGG KILLER to GGG. | 21:52:55 |
| 5 Dec 2024 |
|  Waldemar Tomme joined the room. | 12:51:19 |
|  Toma joined the room. | 18:43:11 |
| lostmsu | A question about Rider and FHS environments: Rider is sort of single instance app, e.g. all windows are actually run by a single instance of Rider. How do you deal with that and the need for FHS environments?
Do I even need FHS environments? Could I make Rider somehow use nix tooling for building packages? | 19:36:26 |
| lostmsu | All these questions arise from the .NET packages that depend on Linux DLLs | 19:40:23 |
| GGG | Corngood: quick question, how does nuget-to-nix determine what packages are SDK ones or not? | 22:01:10 |
| Corngood | It looks for packages that are installed in $NUGET_PACKAGES after restore. Packages from other build inputs are either not installed at all (they get referenced through $NUGET_FALLBACK_PACKAGES), or it skips them by:
# packages in the nix store should have an empty metadata file
used_source="$(jq -r 'if has("source") then .source else "" end' "$version"/.nupkg.metadata)"
found=false
if [[ -z "$used_source" || -d "$used_source" ]]; then
continue
fi
To be clear this goes for all packages that come from other nix derivations, not just SDK ones (even though those are by far the most common right now).
| 22:06:44 |
| GGG | Hm, interesting | 22:07:16 |
| GGG | I'm planning to make that thing you mentioned about referencing SDK packages | 22:07:25 |
| GGG | and I'm gonna add them to the lockfile without a url (or a special URL) | 22:07:41 |
| GGG | that way it removes the unused packages from the SDK since it doesn't need them | 22:07:53 |
| GGG | although that's an issue since we don't have a dependency tree for the SDK packages | 22:08:16 |
| GGG | might leave this for later after all | 22:08:21 |
| Corngood | Yeah, I think that's a can of worms. Think about avalonia. It outputs a bunch of nuget packages, but only some of them may be used by a dependent package. Same problem really. | 22:09:36 |
| GGG | I mean, we have individual packages in the SDK, but we don't have their inter-dependencies | 22:10:08 |
| GGG | like for stuff like metapackages | 22:10:17 |
| GGG | honestly, long term it might be useful to have something akin to ldd to list what assemblies a given assembly depends upon | 22:10:59 |
| GGG | that way we could build a dependency graph | 22:11:15 |
| Corngood | The way the SDK references packages is pretty magical. For example, you may need Microsoft.AspNetCore.App.Ref when building non-aspnetcore stuff. | 22:12:44 |
| Corngood | I have a branch somewhere where I was trying to make the SDK packages opt-in. | 22:13:26 |
| GGG | yeah, that's why I think we might need something like a dependency graph, to identify all that's being used | 22:13:59 |
| Corngood | I discussed the sdk packages quite a bit with 6pak as well | 22:14:00 |
| GGG | or maybe not even a dependency graph, just a bit set of used packages that we recursively walk upon | 22:14:18 |
