| 13 May 2024 |
 raitobezarius | I think most of the features of a binary cache should be in a Nix implementation | 19:14:47 |
| raitobezarius | And then you can carve out various frontends / slight customizations on the top of it IMHO | 19:15:13 |
 danielle | In reply to @raitobezarius:matrix.org
I think most of the features of a binary cache should be in a Nix implementation only if you want your storage and your logic to be the same thing tho | 19:15:37 |
| raitobezarius | Ideally, I'd like to see a way to expose any store as a binary cache in frictionless way | 19:15:40 |
| raitobezarius | In reply to @danielle:fairydust.space
only if you want your storage and your logic to be the same thing tho Your logic can be added on the top IMHO | 19:16:10 |
| raitobezarius | Like if you want authnz, auth, etc. There should be a way to compose existing tools? | 19:16:27 |
 Qyriad | technically a binary cache can take multiple forms; at least one of them should be built in to Nix | 19:16:43 |
| raitobezarius | (generally, I'd like to see the concept of cache combinators) | 19:16:44 |
 samrose | If there is anything people can do to help that are not part of the core team, please let us know. | 19:19:50 |
| raitobezarius | to expand on my thoughts, indeed, binary cache means so many things, I think what would be interesting is:
-
nix has interesting and strong store backends: filesystem, S3, etc.
-
each one of them can be exposed on a reasonable protocol (HTTP/3, etc. whatever) using nix itself
-
nix can handle certain operations by itself which are reasonable: signing store paths (via PKCS#11 or local signing stuff), etc.
-
deduplication should be fundamental & baked-in
-
multi-tenancy should ideally be just multiple nix stores (maybe they can share blocks or something whatever)
-
you can bring your own reverse proxy for auth, authnz based on your "usecase" logic
-
etc.
| 19:20:41 |
| raitobezarius | obviously, you can run a S3 binary cache without nix being around | 19:21:04 |
| raitobezarius | In reply to @samrose:matrix.org
If there is anything people can do to help that are not part of the core team, please let us know. I recommend looking at https://git.lix.systems/lix-project/lix/issues?q=&type=all&state=open&labels=154&milestone=0&assignee=0&poster=0 | 19:21:28 |
| Qyriad | In reply to @samrose:matrix.org
If there is anything people can do to help that are not part of the core team, please let us know. anyone is welcome to contribute! we have a meeting being planned to work out proper governance structure Soon™️ so the "core team" at least as it is right now is largely an interim construct. identifying issues, writing docs or editing the wiki, or code contributions themselves are all very very welcome. on the flip side please let us know if there's anything we can do to help onboard! | 19:22:26 |
| raitobezarius | In reply to @raitobezarius:matrix.org
to expand on my thoughts, indeed, binary cache means so many things, I think what would be interesting is:
-
nix has interesting and strong store backends: filesystem, S3, etc.
-
each one of them can be exposed on a reasonable protocol (HTTP/3, etc. whatever) using nix itself
-
nix can handle certain operations by itself which are reasonable: signing store paths (via PKCS#11 or local signing stuff), etc.
-
deduplication should be fundamental & baked-in
-
multi-tenancy should ideally be just multiple nix stores (maybe they can share blocks or something whatever)
-
you can bring your own reverse proxy for auth, authnz based on your "usecase" logic
-
etc.
(and maybe let me add that i'd like it to be easy to make super-stores by composing a list of stores with any URI format) | 19:22:28 |
|  aria (she/it) changed their display name from aria to aria (she/it). | 19:38:17 |
 jkachmar | In reply to @raitobezarius:matrix.org
i think the binary cache impl should be more or less very sibling to the nix impl this is sort of what the tvix approach is, right?
the store should be a defined component with its own semantics and a clear interface, at which point a lot of other stuff can be implemented on top of this rather than through the current monolithic Nix binary application (e.g. binary caching, the build tool, various bits of UI on top of the store) | 19:42:33 |
| raitobezarius | correct | 19:57:44 |
|  dantefromhell joined the room. | 20:01:59 |
 @tc424:glasgow.social | Oh https://github.com/brianmcgee/nvix | 20:18:40 |
| @tc424:glasgow.social | In reply to @tc424:glasgow.social
Oh https://github.com/brianmcgee/nvix Linked from https://bmcgee.ie/posts/2023/10/nvix-implementing-a-tvix-store-with-nats/ | 20:20:49 |
 MangoIV | In reply to @delroth:delroth.net
the flakes implementation in Lix is arguably more stable than Nix, who broke several user-facing APIs completely through bugs in the past 2-3 versions That’s partially why I was asking, but no answer is good enough as an answer for me now then. I’ll keep watching :) | 20:53:03 |
|  Triskelion changed their display name from Triskelion to Triskelion (AFK). | 21:26:26 |
| samrose | In reply to @tc424:glasgow.social
Linked from https://bmcgee.ie/posts/2023/10/nvix-implementing-a-tvix-store-with-nats/ This looks pretty amazing ... | 21:30:20 |
|  quentin joined the room. | 21:56:14 |
|  easrng joined the room. | 22:38:44 |
| easrng | i just rebuilt with nix.package = pkgs.lix now that it's in nixpkgs and everything seems to work, is there any reason not to do this? | 22:43:16 |
 puck | The version of Lix in nixpkgs will likely lag behind by a bit; and the dedicated overlay/module will build other packages that depend on Nix with Lix as well; which doesn't happen in nixpkgs. | 22:45:37 |
| easrng changed their profile picture. | 22:46:02 |
 mjm | In reply to @easrng:yuri.im
i just rebuilt with nix.package = pkgs.lix now that it's in nixpkgs and everything seems to work, is there any reason not to do this? this is what i'm doing too | 22:46:34 |
| samrose | In reply to @puck:puck.moe
The version of Lix in nixpkgs will likely lag behind by a bit; and the dedicated overlay/module will build other packages that depend on Nix with Lix as well; which doesn't happen in nixpkgs. If we nix build on the flake in the source repo this overlay/module and the packages it builds will be part of the build then, is that right? | 23:08:40 |
