| 29 Nov 2022 |
 tomberek | In reply to @infinisil:matrix.org
John Ericson: tomberek: Joining? Sorry, i missed it. Just came back from a nice Thanksgiving vacation and had a lot to do. | 00:21:40 |
| 30 Nov 2022 |
 infinisil | Aw yeah: https://github.com/nixpkgs-architecture/simple-package-paths/pull/22 | 21:34:08 |
| 1 Dec 2022 |
|  hexa changed their display name from hexa to hexa (22.11 now). | 13:08:47 |
| hexa changed their display name from hexa (22.11 now) to hexa. | 14:38:35 |
| infinisil | I'm not sure what to do about https://github.com/NixOS/nixpkgs/pull/157056. It's about allowing nixpkgs lib to be changeable, e.g. import <nixpkgs> { lib = lib.extend ...; }. I am the one who originally added support lib.extend which enables this, but I'm split about what to do here | 20:37:45 |
| infinisil | Also I'm not even sure if we should be distracted by other things right now, focusing on https://github.com/nixpkgs-architecture/simple-package-paths has worked pretty well. But there are issues like these popping up every now and then. We could also encourage people spending time on such issues to instead help with the NAT efforts. | 20:46:50 |
| infinisil | ncfavier: Oh you're the author of that PR, hello! So yeah, your PR is totally in scope for this team to address, but we are trying to focus and make progress on just a single issue right now which is the above.
And in fact these issues are distantly related in that we're working towards a standardized format for repositories to declare packages, maybe to be combined under pkgs, and this idea could be extended to lib as well. | 20:55:50 |
 Robert Hensing (roberth) | In reply to @infinisil:matrix.org
Also I'm not even sure if we should be distracted by other things right now, focusing on https://github.com/nixpkgs-architecture/simple-package-paths has worked pretty well. But there are issues like these popping up every now and then. We could also encourage people spending time on such issues to instead help with the NAT efforts. As long as we don't discourage people solving their problems. 👍️ | 21:05:11 |
| Robert Hensing (roberth) |
working towards a standardized format for repositories
I feel like to a large degree, nixpkgs will remain unique, with the possible exception of a few private, huge monorepos, or perhaps forks / distros. For instance, sharding is a pain and you'd need a seriously huge org to run into the problem that it solves. Also many repos come with the actual sources, which changes the dynamics.
| 21:09:16 |
 ncfavier | In reply to @infinisil:matrix.org
I'm not sure what to do about https://github.com/NixOS/nixpkgs/pull/157056. It's about allowing nixpkgs lib to be changeable, e.g. import <nixpkgs> { lib = lib.extend ...; }. I am the one who originally added support lib.extend which enables this, but I'm split about what to do here FWIW i don't have strong opinions about this PR anymore | 21:09:26 |
| ncfavier | i still think https://github.com/NixOS/nixpkgs/pull/160459 (extracted from the other one) should be merged though | 21:10:30 |
| infinisil | In reply to @roberthensing:matrix.org
working towards a standardized format for repositories
I feel like to a large degree, nixpkgs will remain unique, with the possible exception of a few private, huge monorepos, or perhaps forks / distros. For instance, sharding is a pain and you'd need a seriously huge org to run into the problem that it solves. Also many repos come with the actual sources, which changes the dynamics.
It could be a setting where the repository could configure whether sharding should be on or not, depending on size | 21:10:51 |
 growpotkin1 | yo I definitely want to follow the lib.extend changes | 21:11:27 |
| growpotkin1 | Or be in on those discussions. I use that a lot. | 21:11:48 |
| growpotkin1 | ( related: I have a long list of pitfalls to avoid ) lol | 21:12:20 |
| Robert Hensing (roberth) | In reply to @infinisil:matrix.org
It could be a setting where the repository could configure whether sharding should be on or not, depending on size When the time comes. Making glue code properly reusable is hard, and it's possible to half-ass it, so the outcome may not be what you want... | 21:14:05 |
| infinisil | In reply to @ncfavier:matrix.org
FWIW i don't have strong opinions about this PR anymore I'm tending towards merging it. It makes a lot of sense with lib.extend existing, which in of itself makes at least some sense, it's like a lib-level overlay system, and it is used a bunch already. | 21:14:12 |
| ncfavier | i guess i should rebase it | 21:15:43 |
| infinisil | Would love to reach consensus with John Ericson on this | 21:17:02 |
 John Ericson | The polyfil thing might convince me | 21:18:54 |
| John Ericson | But I am too busy today to think much about it :( | 21:19:07 |
| infinisil | Sounds good, I'll link to this convo from the PR for future reference | 21:21:08 |
|  raitobezarius joined the room. | 21:30:01 |
|  DwarfMaster joined the room. | 23:46:46 |
| 2 Dec 2022 |
|  @srid:matrix.org changed their profile picture. | 02:19:44 |
| 4 Dec 2022 |
 @ronnypfannschmidt:matrix.org | Something where I'm under the impression that something is missing is the state version concept
For some reason it's bound to the release cadence of nixos instead of matching the granularity of services, which may have migrations (i recently hit this when a failed system update broke my nextcloud by running migrations at update time in turn destroying any chance to run nextcloud after the update) | 17:51:55 |
 Rick (Mindavi) | It makes sense migrations are related to upgrades, no? | 19:21:11 |
| Rick (Mindavi) | The other channel is called unstable for a reason :) | 19:21:25 |
| Rick (Mindavi) | No but I agree that it'd be nice if services handled migrations more gracefully sometimes | 19:23:17 |
| @ronnypfannschmidt:matrix.org | Mindavi: it's kinda necessary to have local state versions and tools around them to contril versions to archive graceful migration
Not just app schema updates, also database versions & more | 19:50:04 |
