| 9 Apr 2024 |
 infinisil | callPackage ({ fetchers, packageSets, ... | 19:15:35 |
|  willbush changed their profile picture. | 22:42:42 |
| 11 Apr 2024 |
|  Anthony Rsl set a profile picture. | 21:59:17 |
| Anthony Rsl removed their profile picture. | 22:12:52 |
| 13 Apr 2024 |
|  terru joined the room. | 23:16:56 |
| 14 Apr 2024 |
 Robert Hensing (roberth) | lib could be a package; lib // { outPath = ../../lib; type = "derivation"; }. done. ;) | 15:23:25 |
| Robert Hensing (roberth) | In reply to @infinisil:matrix.org
callPackage ({ fetchers, packageSets, ... The "cost" of separating out the functions and package sets from the packages in pkgs, is that it exposes the flaw in callPackage that there's a missing indirection between "overridables" (the package function parameters) and their values, which, frequently, aren't pkgs.<name> | 15:26:39 |
| Robert Hensing (roberth) | Turns out I didn't actually support arbitrary overridables yet in single-fixpoint, but that was fixable (pun not intended): https://github.com/NixOS/nixpkgs/pull/296769/commits/b3eddddd4c268866f090934cf4c76ddec909b844 | 15:57:03 |
| Robert Hensing (roberth) | Commit message has an example of how an arbitrary overridable can be added, without touching all-packages.nix (!) | 15:58:00 |
|  @windchimesofmagic:matrix.org left the room. | 17:37:31 |
| 15 Apr 2024 |
| infinisil | Personal office hour now: https://meet.jit.si/nixpkgs-architecture | 18:00:06 |
| infinisil | Cc Philip Taron (UTC-8) willbush | 18:00:22 |
| infinisil | I want to figure out changelogs for nixpkgs-check-by-name today: https://github.com/NixOS/nixpkgs-check-by-name/issues/38 | 18:01:52 |
| 16 Apr 2024 |
| infinisil | Result is really neat, though I had to write some custom scripts: https://github.com/NixOS/nixpkgs-check-by-name/pull/46 | 02:01:24 |
| 17 Apr 2024 |
|  K900 changed their display name from K900 ⚡️ to K9Ö0. | 17:16:43 |
| K900 changed their display name from K9Ö0 to K900. | 17:21:54 |
| K900 | 17:21:55 |
| 18 Apr 2024 |
| infinisil | willbush: Thanks a lot for all the recent reviews, I really appreciate it! ❤️ Would you be interested in getting write access to the repository? :D (cc Philip Taron (UTC-8)) | 12:18:49 |
| willbush | infinisil: No problem! Sure! =D | 14:33:36 |
 Philip Taron (UTC-8) | I think it's a good idea. 👍️ | 16:02:56 |
| infinisil | willbush: Alright! Unfortunately I can't add you right now since you're not part of the NixOS organisation. Can you make a PR to add yourself to https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix? This way you should automatically get an invite for the org, after which I can give you write access | 16:25:29 |
| 19 Apr 2024 |
| infinisil | willbush: You've got write permission now! 🎉 | 05:56:00 |
| willbush | Thanks! | 06:10:02 |
| 20 Apr 2024 |
| willbush | Question on pull request etiquette.
The people I work with at work, we happen to be using GitHub as well, and the person creating the PR usually usually merges the PR. If they want it merged immediately after approval, then they check an auto-merge box (enable in repo settings).
I'm not very experienced working with others in open source (yet :D). What is proper PR etiquette?
| 04:54:40 |
| willbush | * Question on pull request etiquette.
The people I work with at work, we happen to be using GitHub as well, and the person creating the PR usually merges the PR. If they want it merged immediately after approval, then they check an auto-merge box (enable in repo settings).
I'm not very experienced working with others in open source (yet :D). What is proper PR etiquette?
| 04:55:05 |
| willbush | * Question on pull request etiquette.
The people I collaborate with at work, we happen to be using GitHub as well, and the person creating the PR usually merges the PR. If they want it merged immediately after approval, then they check an auto-merge box (enable in repo settings).
I'm not very experienced working with others in open source (yet :D). What is proper PR etiquette?
| 04:55:44 |
| 21 Apr 2024 |
| infinisil | In reply to @willbush:matrix.org
Question on pull request etiquette.
The people I work with at work, we happen to be using GitHub as well, and the person creating the PR usually merges the PR. If they want it merged immediately after approval, then they check an auto-merge box (enable in repo settings).
I'm not very experienced working with others in open source (yet :D). What is proper PR etiquette?
The approach I'm using and I think works really well, is to mark PRs as a draft if you don't think they're ready for merging. So by default, any non-draft PR is ready for merge according to the author | 11:46:57 |
| infinisil | willbush This way, you can also approve a PR, but still wait for others to take a look. Like "LGTM but I'd like @foo to also check it out" | 11:47:48 |
| infinisil | But if you feel confident that nobody else needs to look at it, you can merge it right away | 11:48:29 |
| terru | Question about environment variables which nixpkgs reads to configure itself: these all have the prefix NIXPKGS_ or NIXOS_, except NIX_ABORT_ON_WARN. I find this very confusing, as it suggests that this variable is read by nix itself, which it is not. It was introduced in #140763, apparently without consideration of this inconsistency. Is there any good reason why it should not be called NIXPKGS_ABORT_ON_WARN instead, and if not, what is the process to change it? rename it, and for a release cycle still also accept the old variant, but produce a trace if it is set? | 17:22:53 |
