| 11 Oct 2023 |
|  Guillaum joined the room. | 07:09:48 |
| Guillaum | Hello. I'm nixGL (https://github.com/guibou/nixGL) author and my friend teto suggested that nixGL can be moved to nix community. I have no time / motivation / available hardware / use case anymore for nixGL, but apparently that's used, so I'll be more than happy to give it to the community.
What could be the next step? | 07:12:24 |
 teto | I see much people talking about it, home-manager integration etc and I know you dont have time to work on it so I think nix-community is a good solution | 07:16:08 |
 TheSola10 | i'd like an opinion on my proposal https://github.com/NixOS/nix/issues/9141 | 07:39:47 |
| TheSola10 | this would basically remove the burden from flake_registry.json | 07:41:12 |
 raitobezarius | Pardon me for the words | 07:41:50 |
| raitobezarius | But that's a non starter IMHO | 07:41:57 |
| raitobezarius | I don't see why FlakeHub should be preferred given it's not community infrastructure neither project owned infrastructure | 07:42:19 |
| TheSola10 | knew it, i wasn't sure about the standing, but regardless of whether it's flakehub or another platform, the FlakeHub approach to flake indexing and versioning feels like a good match for flake shortnames | 07:43:09 |
| raitobezarius | Also I'd highly suggest discussing this in channels like #dev:nixos.org | 07:43:24 |
| raitobezarius | In reply to @thesola10:matrix.org
knew it, i wasn't sure about the standing, but regardless of whether it's flakehub or another platform, the FlakeHub approach to flake indexing and versioning feels like a good match for flake shortnames Possibly | 07:45:07 |
| raitobezarius | I don't think your proposal should be made dependent on Flakehub then | 07:45:27 |
| raitobezarius | But on any implementation of the idea | 07:45:34 |
| raitobezarius | Though I am not so convinced about DockerHub style feature in a community project | 07:45:51 |
| TheSola10 |
In addition, this could also mean a nix config option to allow sysadmins to override the "default namespace", like a rewrite rule:
but yea
| 07:45:55 |
| TheSola10 | well we are heavily reliant on github anyway | 07:47:12 |
| TheSola10 | having a "home platform" could encourage decentralization, like pushing from self-hosted GitLabs and Giteas | 07:47:48 |
| TheSola10 | as well as providing a "chain of trust" between a flake source and, say, a matching Cachix | 07:48:36 |
| raitobezarius | It seems fragile to further build on the flake abstraction in this manner | 07:49:31 |
| raitobezarius | But if Flakes proponents want it this way and Nix core team find a way to make place for that, it's not my business | 07:50:03 |
| raitobezarius | I don't think decentralization is a goal that this proposal is particularly solving in any way | 07:50:32 |
| raitobezarius | But that may be because most of the stuff I do already consumes from 30 different forges with Nix just fine without Flakes | 07:51:24 |
| raitobezarius | So I must not be the target for this stuff | 07:51:30 |
| raitobezarius | Providing chain of trust between flake source and a cache is probably a misfeature as it is right now because it reintroduces imperative management and breaks the local scoping expectations | 07:52:24 |
| raitobezarius | In my opinion at least | 07:52:32 |
| raitobezarius | It's convenient but at what cost of the years of cultural shift we have been pursuing | 07:52:48 |
| raitobezarius | Again don't let this opinion discourage you from pursuing what you feel is a good thing | 07:53:48 |
| raitobezarius | I am not really the good audience for Flakes related stuff based on my own experience as a Nixpkgs developers | 07:54:49 |
| raitobezarius | * I am not really the good audience for Flakes related stuff based on my own experience as a Nixpkgs developer | 07:54:58 |
|  ghpzin joined the room. | 08:00:44 |
