| 28 Jan 2024 |
 @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 |
|  Finn Landweber joined the room. | 15:02:12 |
| Finn Landweber 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 |
| 1 Feb 2024 |
| @qyriad:matrix.org | In reply to @aliarokapis:matrix.org
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. LLVM's stdenv's are overrideCCs on base stdenv: https://github.com/NixOS/nixpkgs/blob/e4f711a40e2124d11f84c3e67443d02fa413a634/pkgs/development/compilers/llvm/16/default.nix#L319 | 00:32:30 |
