| 23 Aug 2025 |
 emily | (by need I mean: the old one will cause problems with CMake 4) | 23:15:41 |
 raitobezarius | In reply to @emilazy:matrix.org
so most users will be using their actual Nixpkgs if they set the follow i'm a non flake user :D | 23:18:14 |
| emily | actually it is not even about the flake input, I was wrong | 23:18:51 |
| emily | it sets an overlay | 23:18:53 |
| raitobezarius | yeah | 23:18:57 |
| emily | so it will be using the NixOS system's package set, regardless | 23:18:59 |
| raitobezarius | hm yep | 23:19:10 |
| 24 Aug 2025 |
 Lunaphied | Uhhhh | 00:28:08 |
| Lunaphied | hm something about that seems off | 00:28:13 |
| Lunaphied | In reply to @raitobezarius:matrix.org
i'm a non flake user :D I really need to get around to that change with supporting overrides in flake-compat | 00:28:36 |
| raitobezarius | just give me https://git.afnix.fr/sprinkles/sprinkles | 00:29:20 |
| Lunaphied | o.o what's this exactly? | 00:34:46 |
| raitobezarius | Charles attempts to bring a flake structure to the non-flake world | 00:35:05 |
| raitobezarius | i personally like it, it's growing on me certainly | 00:35:16 |
| Lunaphied | hm, I guess we should look at that | 00:45:17 |
| emily | "source and input must be the only variables defined in the let binding." maintaining the vital flakes property of not being Nix I see :P | 01:03:49 |
 Charles | that's mainly there to keep the structure consistent; if you want to define arbitrary stuff i usually have a let binding inside output like
{
output = self:
let
inherit (self.input) nixpkgs;
foo = 4;
in
{
shell.default = nixpkgs.callPackage ./shell/default { inherit foo; };
};
}
for example. other major difference from flakes is that e.g. source = import ./lon.nix; works and is a totally reasonable thing to do
| 01:23:08 |
| Charles | if you really don't want to follow a convention, then not following the convention is also an option, but then you don't get the benefits of following the convention | 01:24:40 |
| Charles | * that's mainly there to keep the structure consistent and make overrideability more consistently available; if you want to define arbitrary stuff i usually have a let binding inside output like
{
output = self:
let
inherit (self.input) nixpkgs;
foo = 4;
in
{
shell.default = nixpkgs.callPackage ./shell/default { inherit foo; };
};
}
for example. other major difference from flakes is that e.g. source = import ./lon.nix; works and is a totally reasonable thing to do
| 01:26:23 |
| Charles | * that's mainly there to keep the structure consistent and make overrideability more consistently available; if you want to define arbitrary stuff i usually have a let binding inside output like
# [stuff]
{
# [stuff]
output = self:
let
inherit (self.input) nixpkgs;
foo = 4;
in
{
shell.default = nixpkgs.callPackage ./shell/default { inherit foo; };
};
}
for example. other major difference from flakes is that e.g. source = import ./lon.nix; works and is a totally reasonable thing to do
| 01:27:02 |
| emily | re "make overrideability more consistently available", is there non-Nix stuff parsing these files? (I'm struggling to understand what forbidding other let bindings achieves) | 01:32:12 |
| Charles | nope | 01:32:28 |
| Charles | when i say overrideability i mean the ability to do someSprinkle.override { source = { ... }; input = source: { ... }; } and have it affect everything in someSprinkle that should be affected | 01:33:50 |
| Charles | there's not that much code for sprinkles.new but it is pretty dense, might help to try reading that to get an idea of what's going on?
- https://git.afnix.fr/sprinkles/sprinkles/src/branch/v1/nix/lib/default.nix
- https://git.afnix.fr/sprinkles/sprinkles/src/branch/v1/nix/lib/private.nix
| 01:35:14 |
| emily | ah, so the worry is capturing sprinkles in other definitions I suppose? | 01:35:20 |
| Charles | not entirely sure what you mean | 01:37:20 |
| Charles | i think i would maybe phrase it more like "the worry is being able to influence sources and inputs of other sprinkles"? | 01:38:02 |
| emily | with a private let binding? I'm confused :) | 01:38:31 |
| emily | the only non-fixed thing in scope of the let is sprinkles (since "sprinkles ? null must be the only formal argument of the file"), so the only way another definition in the top-level let could impede overridability is by referencing sprinkles when it shouldn't, right? | 01:39:17 |
| emily | vs. a let inside output | 01:39:19 |
