| 6 Feb 2023 |
 @blaggacao:matrix.org | I feel also really uncomfortable that we discuss this here, off topic. Apologies to everybody! | 22:06:31 |
| @blaggacao:matrix.org left the room. | 22:06:43 |
| 7 Feb 2023 |
 John Ericson | https://discourse.nixos.org/t/adding-pkg-config-metadata-to-nixpkgs-packages/25281 | 04:21:58 |
 Sandro 🐧 | In reply to @Ericson2314:matrix.org
https://discourse.nixos.org/t/adding-pkg-config-metadata-to-nixpkgs-packages/25281 The design of this seems really rushed to me. Immediately several people noted the boiler platy parts and why it doesn't happen automatically when meta.pkgConfigModules is provided. | 12:16:26 |
| Sandro 🐧 | also on a side note: pkgConfigModules looks kinda strange in camel. | 12:16:45 |
| John Ericson | Sandro 🐧: to be clear that is not an official project of this Nixpkgs Arch team | 12:33:08 |
| Sandro 🐧 | we can also move this discussion to #dev:nixos.org | 14:39:21 |
| 9 Feb 2023 |
|  alexshpilkin joined the room. | 01:57:07 |
| 13 Feb 2023 |
 Robert Hensing (roberth) | I'll probably be late to today's meeting | 15:20:06 |
| Robert Hensing (roberth) | feel free to start | 15:20:14 |
 infinisil | @room: The next meeting will take place in ~10 minutes, we'll discuss RFC 140, in particular the naming of the pkg-fun.nix file - meeting link - live stream - meeting notes | 15:20:46 |
| infinisil | growpotkin ( Alex Ameen ): John Ericson: Joining? | 15:32:27 |
| 16 Feb 2023 |
|  Bryan Honof changed their profile picture. | 14:22:25 |
| 17 Feb 2023 |
|  kevincox changed their profile picture. | 20:32:15 |
| kevincox changed their profile picture. | 20:33:27 |
| 19 Feb 2023 |
 @ronnypfannschmidt:matrix.org | would it make sense to make a option type that would allow attrset of derivations or list of derivations for the packages options
{pkgs, ...}: environment.systemPackages ={ inherit (pkgs) qtpass }
imho this would feel more natural than using the dotted notion or attrValues, while avoiding the pitfall of the with statement
| 12:19:06 |
| infinisil | Ronny: An option type for that already exists, attrsOf package. The bigger issue is backwards compatibility and maybe a way to still use lists but have them be coerced to an attribute set | 13:22:36 |
| infinisil | But I 100% agree that we should be able to specify packages using attribute sets | 13:23:34 |
| @ronnypfannschmidt:matrix.org | In reply to @infinisil:matrix.org
Ronny: An option type for that already exists, attrsOf package. The bigger issue is backwards compatibility and maybe a way to still use lists but have them be coerced to an attribute set i specifically meant a option type that will allow both lists and attrsets and coerce them into lists, for merge
my understanding is that same name packages in different sets are possible when they dont actually conflict
| 13:25:21 |
| infinisil | Ronny: Coercing to a list won't have any of the benefits of attribute sets though | 13:26:32 |
| infinisil | One of the main ones being the ability to remove a package | 13:26:57 |
| @ronnypfannschmidt:matrix.org | removal is currently not possible anyway as far as i understood
imho a good starting point is to etablish using attr sets early and as default so people can migrate to using the better syntax
and once the majority o usages are changed its time to enable extra features
nontheless it seems potentially terrifying if other modules are allowed to remove packages of the sets | 13:30:02 |
| infinisil | Ronny: If we can coerce from lists to attribute sets there will be no need for attribute set syntax though, while still getting the benetifs of attribute sets. And the implementation can indeed work by using either the package name as an attribute name, or using the attribute path to the package (a bit harder) | 13:40:34 |
| infinisil | In reply to @ronnypfannschmidt:matrix.org
removal is currently not possible anyway as far as i understood
imho a good starting point is to etablish using attr sets early and as default so people can migrate to using the better syntax
and once the majority o usages are changed its time to enable extra features
nontheless it seems potentially terrifying if other modules are allowed to remove packages of the sets This is already the case though, all modules can do anything to the system id they want to, they all have root access so to speak | 13:41:28 |
| infinisil | In reply to @ronnypfannschmidt:matrix.org
removal is currently not possible anyway as far as i understood
imho a good starting point is to etablish using attr sets early and as default so people can migrate to using the better syntax
and once the majority o usages are changed its time to enable extra features
nontheless it seems potentially terrifying if other modules are allowed to remove packages of the sets * Regardjng allowing modules tk remove options: This is already the case though, all modules can do anything to the system id they want to, they all have root access so to speak | 13:42:22 |
| infinisil | (Damn, made a lot of typos on my phone in the train, but the matrix client somehow doesn't let me edit multiple times) | 13:44:24 |
| 20 Feb 2023 |
| Robert Hensing (roberth) | In reply to @infinisil:matrix.org
Regardjng allowing modules tk remove options: This is already the case though, all modules can do anything to the system id they want to, they all have root access so to speak Imports into submodules don't, unless they're facilitated to do such things by a module that interacts with the submodule (usually the module that declares the submodule) | 11:25:41 |
| infinisil | @room: The next meeting will take place in ~10 minutes - meeting link - live stream - meeting notes | 15:23:00 |
| infinisil | tomberek: growpotkin ( Alex Ameen ) Pairing time :) | 16:47:16 |
| Robert Hensing (roberth) | nice performance improvement and cleanup: https://github.com/NixOS/nixpkgs/pull/217243 | 23:09:28 |
