24 Aug 2025 |
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 |
Charles | sprinkles.new takes an attrset with 3 arguments, output , source, and input ; and accessing stuff through self in output = self: ...; will give you the overridden version of source s and input s if they were overridden by a caller | 01:40:00 |
emily | I don't understand what that has to do with what names you're allowed to define in the top-level let (but also feel bad about having spent this much time on off-topic stuff anyway) | 01:41:25 |
Charles | could move to a DM if you want? | 01:41:51 |
emily | oh, maybe you mean the worry is other bindings referencing source ? | 01:42:07 |
emily | sure if you'd like :) | 01:42:10 |
aloisw | Sure, my point is that I think it will stay around longer if it's not separate, due to the deadlock. | 05:30:04 |
aloisw | Regarding the recursive lambda issue bumping nixpkgs sounds good to me. 2.91 will probably also need its C++ standard to be changed to C++23. | 05:31:09 |
raitobezarius | <3 aloisw on openssl | 17:46:20 |