| 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 |
| 21 Feb 2023 |
 Sandro 🐧 | Two things:
- we shouldn't use the hello package to accumulate all kinds of tests
- hello should definitely not have __cleanAttrs set
| 00:09:35 |
| Sandro 🐧 | Also I currently don't see the usecase why we would want to set __cleanAttrs on any package. It has the UX of moving everything into a let in and breaking all extensibility. | 00:13:46 |
 Artturin | In reply to @sandro:supersandro.de
Also I currently don't see the usecase why we would want to set __cleanAttrs on any package. It has the UX of moving everything into a let in and breaking all extensibility. Why moving everything to let in? | 04:32:28 |
| Artturin | rec and finalAttrs should works as they do now | 04:33:43 |
| Artturin | It's possible to have finalAttrs values in passthru right? | 04:33:56 |
| Artturin | I think it'll be useful to have to explicitly declare all attrs that should be available outside of the package | 04:35:59 |
| Artturin | * I think it'll be useful to have to explicitly declare all public attrs | 04:36:37 |
| Sandro 🐧 | I was comparing it to having variables in let ins.
| 11:51:01 |
| Sandro 🐧 | Packages should expose all attrs written in the file otherwise overlays will become unnecessarily hard and right now I am completely against using it in any normal package. | 11:52:26 |
| Artturin | In reply to @sandro:supersandro.de
Packages should expose all attrs written in the file otherwise overlays will become unnecessarily hard and right now I am completely against using it in any normal package. it won't affect overlays https://github.com/NixOS/nixpkgs/pull/217243#issuecomment-1438756128 | 17:29:00 |
| Artturin | In reply to @sandro:supersandro.de
Packages should expose all attrs written in the file otherwise overlays will become unnecessarily hard and right now I am completely against using it in any normal package. * it won't affect override overlays https://github.com/NixOS/nixpkgs/pull/217243#issuecomment-1438756128 | 17:29:11 |
| Sandro 🐧 | If you are using overrideAttrs but sometimes you are constructing a new package by copying pname, version, src and patches from another package. Not exposing them by default just creates busy work and friction for downstream users. | 18:19:09 |
| 23 Feb 2023 |
|  @alejandrosame:matrix.org joined the room. | 17:54:27 |
