| 16 Feb 2025 |
 antifuchs | Oh wait, isn’t example 254 exactly that? | 04:07:53 |
 Charles | kinda | 04:08:34 |
| antifuchs | ETOOFUNCTIONAL for my brain atm | 04:08:37 |
| Charles | 254 uses callPackageWith to construct the value for newScope, but i want to use an existing other value for that | 04:09:10 |
| Charles | e.g. nixpkgs.newScope | 04:09:15 |
| Charles | so... this works:
callPackage = fn: args:
scope.callPackage
fn
(args // (
let
loadedFn = if builtins.isFunction fn
then fn
else if builtins.isPath fn
then import fn
else builtins.throw "???";
requiresSprinkle = builtins.hasAttr
"sprinkle"
(builtins.functionArgs loadedFn);
in
if requiresSprinkle
then { sprinkle = self; }
else {}
));
| 04:24:48 |
| Charles | now i'm getting infinite recursion presumably because i have packages like { foo }: (foo.override { bar = true; }) that retain the same name in my newly created scope from their original scope, but what's weird is that this wasn't happening before | 04:27:35 |
| Charles | maybe makeScope is the wrong abstraction and i need to use callPackageWith manually, i dunno | 04:28:45 |
| antifuchs | Yeah, possibly. I’m not sure what the value of the scope is considering you can also do mutually-dependent packages with callPackageWith. Maybe eval speed | 04:32:05 |
| Charles | tbh i think the point of makeScope is to avoid this exact infinite recursion issue i'm hitting | 04:33:17 |
 llakala | In reply to @charles:computer.surgery
makeScopedPackagesFromDirectoryRecursive = newScope: directory:
nixpkgs.lib.customisation.makeScope newScope (scope:
nixpkgs.lib.filesystem.packagesFromDirectoryRecursive {
inherit directory;
callPackage = fn: args:
scope.callPackage
fn
(args // { sprinkle = self; });
}
);
not to interrupt but i have to share this extremely long function name i just wrote
I wrote something similar which may be helpful as a reference | 04:33:28 |
| llakala | https://github.com/llakala/llakaLib/blob/main/lib/collectDirectoryPackages.nix | 04:34:06 |
| Charles | oh interesting | 04:34:31 |
| llakala | the noogle documentation here is also really good | 04:34:48 |
| llakala | here's a usage example https://github.com/llakala/llakaLib/blob/2512d32d7812b62d27d9a63017fa1e4c91214d90/flake.nix#L42 | 04:35:42 |
| Charles | oh i think i get it, this is very clever | 04:37:03 |
| Charles | shouldn't localWrapper // pkgs be the other way aroudn? | 04:37:48 |
| Charles | * shouldn't localWrapper // pkgs be the other way around? | 04:37:50 |
| llakala | hmm will the order matter? | 04:38:03 |
| llakala | I guess maybe it will | 04:38:18 |
| llakala | that's smart | 04:38:20 |
| Charles | yes, values in the latter attrset with the same name take precedence | 04:38:20 |
| llakala | wait yeah that's VERY smart | 04:38:30 |
| llakala | I'll make a note to fix that tomorrow, thanks :3 | 04:38:39 |
| Charles | { a = "a"; } // { a = "b"; } -> { a = "b"; } for example | 04:38:49 |
| Charles | wait no actually i think localWrapper // pkgs is correct | 04:40:45 |
| Charles | because if i try flipping them i get infinite recursion, but if i don't flip them, then it works | 04:41:00 |
| llakala | it doesn't matter as much in this case, because merging with localWrapper results in a top-level attribute localPackages, e.g.
```
{ pkgs, localPackages }:
```
but the only reason I HAD to create the localWrapper attribute was because of issues with shadowing, and swapping the order would've been an alternate way to fix it | 04:41:05 |
| Charles | i'm not sure if it works as expected, but it at least evals | 04:41:12 |
| llakala | In reply to @charles:computer.surgery
because if i try flipping them i get infinite recursion, but if i don't flip them, then it works interesting | 04:41:16 |
