| 18 Dec 2024 |
 6pak | how would that work | 19:40:43 |
| 6pak | different sources can have different package contents for the same version | 19:40:52 |
| 6pak | tbh it could error out in that case, but it doesn't | 19:41:02 |
| 6pak | it just takes the first result | 19:41:06 |
 Corngood | So does this build a derivation? How do you make it unique on consecutive runs? | 19:41:23 |
| 6pak | it relies on impure-derivations | 19:41:42 |
| Corngood | it actually uses the first one to respond or something insane like that | 19:41:45 |
| 6pak | which afaik makes it always rebuild | 19:41:47 |
| 6pak | and allows internet access | 19:41:49 |
| Corngood | so an impure derivation will always rebuild? interesting | 19:42:13 |
| 6pak | that seems to be happening from what I see | 19:42:34 |
| 6pak | I would use --rebuild but that result in a non descriptive error for impure derivations, for some reason | 19:43:06 |
| 6pak | * I would use --rebuild but that result in a non descriptive error for impure derivations, for some reason (https://github.com/NixOS/nix/issues/9782) | 19:43:31 |
| Corngood |
This is by design, sources are unordered and they are searched by order of the quickest response rather than by order of how they show up in file.
https://github.com/NuGet/Home/issues/3676
| 19:44:26 |
| 6pak | huh | 19:44:51 |
| Corngood | I'm not sure how things have changed since then. But that was why nuget-to-nix had to check all the sources for each package :| | 19:45:04 |
| 6pak | if that's still the case then thats one more reason to always use package mapping | 19:45:38 |
| 6pak | * if that's still the case then thats one more reason to always use package source mapping | 19:45:58 |
| Corngood | You can still end up with multiple sources as options for a package | 19:46:22 |
| 6pak | if that's still the case then I guess what I observed was simply the result of the first source being the first request made | 19:47:10 |
| 6pak | because changing the order did change which package was resolved for me | 19:47:34 |
| Corngood | on the sandbox thing, how do you copy the output file into nixpkgs? that's one nice thing about using firejail for fetch-deps, update scripts, etc. you can easily give it write access to just the nixpkgs repo | 19:49:26 |
| 6pak | outer fetch-deps script is the one invoking the sandboxed build | 19:50:14 |
| Corngood | I guess you still run an outer script outside of the sandbox? | 19:50:18 |
| 6pak | yeah | 19:50:23 |
| 6pak | the protection more is against malicious build scripts in upstream rather than nixpkgs code | 19:50:39 |
| 6pak | * the protection is more against malicious build scripts in upstream rather than nixpkgs code | 19:50:50 |
| Corngood | I wonder if anyone has discussed sandboxing of update scripts anywhere. that's basically the same thing but more widely used | 19:51:16 |
| 6pak | is nixpkgs-update bot even sandboxed? | 19:52:46 |
| Corngood | I'd certainly hope so, but I have no idea where/how it runs. | 19:53:39 |
