Nix + dotnet | 118 Members | |
| 23 Servers |
| Sender | Message | Time |
|---|---|---|
| 23 Dec 2024 | ||
| Sorry, what's efcore? | 00:49:03 | |
| EntityFrameworkCore, the package that's crashing in your log | 00:49:24 | |
| Ah I'll try to look into how to do that. Thank you for the suggestion! | 00:50:15 | |
| Well judging by the lock file it seems to be using the same version as pre release. So if anything I think maybe it was meant to work with an older version? | 00:51:01 | |
| wait why does it reference both ef6 and efcore | 00:51:38 | |
| it doesn't | 00:52:41 | |
| lts uses 3.1, prerelease uses 7.0 | 00:52:46 | |
| * lts uses 3.1.5, prerelease uses 7.0.1 | 00:53:01 | |
| the ef6 reference is just for decoration I guess | 00:53:23 | |
| Ah, I was looking at `pname = "EntityFramework"; version = "6.4.4"` | 00:53:47 | |
| I'm not familiar with these packages at all. I also don't remember what happened when it was left targeting netcoreapp3.1. that should be possible with a newer sdk, right? | 00:54:53 | |
| I'll see if I can play around with any of this at some point. Thank you both so much for the thoughts! | 01:05:25 | |
So this worked!
| 03:50:00 | |
(I removed a bunch from patchPhase for the above example) | 03:53:18 | |
I'd recommend using patch files whenever possible instead of substituteInPlace | 03:58:38 | |
| but if you've ensured that it only changes the versions of what you want then it should be fine | 03:59:01 | |
| That's a good tip, thanks | 03:59:59 | |
As far as I can tell, the only things that I'm changing are what I intend to, so I should be good. | 04:01:22 | |
(Honestly I just prefer substituteInPlace since it leaves a cleaner directory, but honestly I should just use patch files instead since that will make the actual derivation cleaner.) | 04:02:14 | |
| I myself prefer patch files because they ensure that things break if the file isn't the same anymore | 04:02:34 | |
| instead of just possibly silently changing things they shouldn't | 04:02:47 | |
| That's certainly a good point. Most of what I'm modifying (other than this) are hard to mis-patch so I'm not really worried, but hey that is still a very good reminder. https://github.com/Whovian9369/aaru-nix-flake/blob/620ef8866395544b5aad55b7dac83fa63a988731/lts.nix#L36-L79 | 04:07:20 | |
On prerelease and git I'm only doing --replace-fail '{chash:8}' "${substring 0 8 src.rev}" which I'm pretty confident aren't going to mis-match at all even between updates.(If those change at all, like if one gets removed, I'm sure that I'll figure it out pretty easily and add it to the extensive file list.) | 04:10:32 | |
| 24 Dec 2024 | ||
| GGG replied to your question about buildPackages | 00:56:32 | |
| if after reading the link you are still confused, don't worry, I think everyone is | 00:56:42 | |
| imo the mess comes from the implicit splicing mechanic, it would be much clearer if you were forced to explicitly reference the package set but oh well | 00:57:54 | |
| Huh, I thought `hostPlatform` was already the machine it's being built on | 01:00:43 | |
| hostPlatform is the host that will run the package | 01:01:04 | |
| buildPlatform is the host that is building the package | 01:01:17 | |
| targetPlatform is a special thing for target-specific packages, like the GCC compiler | 01:01:43 | |