| 28 Jan 2024 |
|  @jade_:matrix.org joined the room. | 23:53:24 |
| @jade_:matrix.org | something I've found often very difficult to work with while doing nixpkgs work that i was reminded of in a recent review by infinisil and Robert Hensing (roberth) is that stuff that's not lib and is in fact packaging related is all slammed into all-packages.nix in the flat namespace with a bunch of packages that are not special
I'm wondering if stuff like fetchers, recurseIntoAttrs, newScope, pkgs.path and so on should get a new secondary namespace to make them easier to find out about.
also as an example, stuff like nix-update isn't obvious to new contributors who don't have long standing dms with raito to be told about them :p | 23:57:26 |
| 29 Jan 2024 |
 infinisil | jade_ Yeah fully agreed! I think we should totally have separate namespaces for the different "type" of values | 00:05:19 |
| infinisil | Kind of like a very primitive type system haha | 00:05:32 |
| @jade_:matrix.org | maybe the way to think about it also is how an ideal reference documentation would look | 00:09:33 |
| @jade_:matrix.org | and then organize based on how you'd think about that | 00:09:44 |
| @jade_:matrix.org | like fetchers, scopes, misc, idk | 00:10:32 |
| infinisil | 💯 | 00:10:50 |
| infinisil | pkgs/by-name is one small step in that direction, because that's a place where only packages are allowed, putting e.g. functions in there isn't allowed by CI | 00:11:26 |
| @jade_:matrix.org | yes good | 00:11:36 |
| @jade_:matrix.org | oh also i found a use for the isFlake feature even if my pkgs path thing gets canned: improving the errors for stuff where we ask for env-vars for broken, insecure, or proprietary packages | 00:24:04 |
 K900 | pkgs/by-name/c-/c-periphery/package.nix | 07:53:15 |
| K900 | That's a funny edge case | 07:53:17 |
|  Sam Lehman joined the room. | 11:01:00 |
| Sam Lehman set a profile picture. | 11:06:02 |
|  @flandweber:envs.net joined the room. | 15:02:12 |
| @flandweber:envs.net changed their display name from flandweber to Finn Landweber. | 18:20:07 |
| 30 Jan 2024 |
| infinisil | There is one remaining problem with the current pkgs/by-name check, and this fixes it: https://github.com/NixOS/nixpkgs/pull/285089
Quite a bit of Rust code there, would appreciate a review
| 20:49:34 |
| infinisil | I added tests and comments | 20:49:49 |
| infinisil | (actually just discovered another issue, but that one's pretty easy to fix) | 21:27:25 |
| infinisil | Easy and touching the same parts of the code, so I just included it in the above PR too as the last commit | 21:56:28 |
| 31 Jan 2024 |
|  @federicodschonborn:matrix.org changed their profile picture. | 03:36:13 |
| @federicodschonborn:matrix.org changed their profile picture. | 06:21:49 |
 Alexandros Liarokapis | Are there any documented requirements for what constitutes a valid stdenv? | 21:31:45 |
| infinisil | Pretty sure the answer is No and I personally don't have the knowledge to write that 😅 | 22:27:31 |
| Alexandros Liarokapis | Its kind of funny sincenit is so integral to the whole ecosystem | 22:38:52 |
 @qyriad:matrix.org | Most alternate stdenvs are derived from stdenv in someway anyway right? | 23:01:11 |
| Alexandros Liarokapis | I am not sure if that is the case with llvmPackages.stdenv and there are also some other stdenvs with other compilers both in stdenv and in various third party flakes. | 23:21:20 |
 tomberek | First question is what you mean by "valid". If you mean compatibility with mkDerivation and its semantics, then that will be complicated. Just making nix-shell/develop work is easy. | 23:36:50 |
| Alexandros Liarokapis | Yea I mean compatible with mkDerivation and other nixpkgs assumptions like the isPlatform checks and others | 23:43:15 |
