| 18 May 2025 |
 Whovian9369 | Are you saying in respect to what Upstream should do, or what I should do for my Nix packaging? | 22:53:28 |
 6pak | what upstream should do | 22:53:50 |
| 6pak | you probably should just ^ | 22:53:57 |
| 6pak | global.json doesn't really matter because you specify the sdk version in nix anyway | 22:54:26 |
| 6pak | and if the build really breaks (or anything other unwanted) on 9.0.2xx, just specify sdk_9_0_1xx in nix | 22:55:07 |
| Whovian9369 | I imagine this would still be an issue with rollForward=latestPatch due to our dotnet version being newer, but I'd agree (from my non-programming background) that it sounds like a reasonable suggestion.
$ nix develop .#git
warning: Git tree '/home/whovian/.flakes/aaru' is dirty
[whovian@nixos-wsl:~/.flakes/aaru]$ dotnet --version
9.0.203
| 22:55:26 |
| 6pak | * and if the build really breaks (or anything other unwanted happens) on 9.0.2xx, just specify sdk_9_0_1xx in nix | 22:55:31 |
| Whovian9369 | Cool, thank you very much! | 22:55:33 |
| 6pak | you'd specify sdk_9_0_1xx then, yeah | 22:56:16 |
| Whovian9369 | Thank you for the thoughts! | 22:57:15 |
| 6pak | fyi (at least for now) the 1xx feature band is supported for the whole .net version lifetime | 22:57:15 |
| 6pak | while 2xx and 3xx get EOLed until you land on 4xx | 22:57:27 |
| Whovian9369 | That seems interesting. | 22:57:59 |
| 6pak | because source build officially supports only 1xx | 22:58:36 |
| 6pak | so newer feature bands are MS binaries only | 22:58:51 |
| 6pak | * so later feature bands are MS binaries only | 22:58:58 |
| Whovian9369 | patchPhase = ''
# Remove global.json to prevent build issues stemming from its existence.
# We're pinning to an SDK version by using Nix anyway, so it's not super
# important to worry about Upstream's set version.
rm global.json
'';
So this seems to have worked fine. Thank you again for the thoughts!
| 23:10:35 |
| Whovian9369 | That's very interesting. Thank you for the thoughts! | 23:10:47 |
| Whovian9369 | * patchPhase = ''
# Remove global.json to prevent build issues stemming from its existence.
# We're pinning to an SDK version by using Nix anyway, so it's not super
# important to worry about Upstream's set version.
rm global.json
'';
So this seems to have worked fine. Thank you again for the thoughts!
| 23:11:00 |
| 6pak | you probably want postPatch, but yeah, lgtm | 23:23:03 |
| Whovian9369 | Oh, do you have a specific thought on why I should be using postPatch instead of patchPhase for this? | 23:23:37 |
| Whovian9369 | I'm also doing more in patchPhase than just what I put above, so if you think moving that rm to postPatch instead is good then I'll probably just move the whole block. | 23:24:50 |
| Whovian9369 | * I'm also doing more in patchPhase than just what I put above, so if you think moving that rm to postPatch instead is good then I'll probably just rename the whole block. | 23:24:58 |
| 6pak | overriding patchPhase will break patches iirc | 23:24:58 |
| Whovian9369 | Eh fair, I'll probably split it into two commits (updating and then swapping to postPatch) - Thanks for the thoughts! | 23:26:04 |
| 27 May 2025 |
|  @deeok:matrix.org joined the room. | 19:17:22 |
| 28 May 2025 |
|  crgre joined the room. | 15:18:28 |
|  dish [Fox/It/She] left the room. | 15:21:57 |
| 29 May 2025 |
| Whovian9369 | Hey, I'm here again to cause issues. :P
I'm trying to work with Nuke.Common to properly do part of a build, and fetch-deps is throwing MSBUILD : error MSB1009: Project file does not exist.
$ nix build -L .#default.passthru.fetch-deps -o fetch-deps
$ ./fetch-deps deps.json
fetching dependencies for test-2024.08.29
Running phase: unpackPhase
unpacking source archive /nix/store/xfrqd606lr502c3z0dm5y84ljzr1x5nr-source
source root is source
Running phase: patchPhase
Running phase: configureNuget
The template "NuGet Config" was created successfully.
Processing post-creation actions...
Running phase: updateAutotoolsGnuConfigScriptsPhase
Running phase: configurePhase
Determining projects to restore...
Restored /tmp/fetch-deps-test-2024.08.29.9gDEqK/source/build/_build.csproj (in 4.55 sec).
MSBUILD : error MSB1009: Project file does not exist.
Switch: dirs.proj
| 02:14:32 |
| Whovian9369 | Does anyone happen to have any ideas? | 02:14:42 |
