| 31 Jan 2024 |
|  @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 |
| @qyriad:matrix.org | I don't know about the others though | 00:32:35 |
 raitobezarius | I am aware of stdenv non derived by nixpkgs and those are completely different beast having their own semantics | 01:42:51 |
| raitobezarius | Before documenting what is a valid nixpkgs abiding stdenv, I think if we can document how to derive more complicated stdenv using combinators, that'd be great | 01:43:10 |
| raitobezarius | Documenting a valid nixpkgs abiding stdenv is bound to be very complicated notably due to splicing constraints, etc. which are not even totally clear for experts | 01:43:29 |
| @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 stdenvs are overrideCCs on base stdenv: https://github.com/NixOS/nixpkgs/blob/e4f711a40e2124d11f84c3e67443d02fa413a634/pkgs/development/compilers/llvm/16/default.nix#L319 | 02:05:09 |
 @jade_:matrix.org | In reply to @aliarokapis:matrix.org
Yea I mean compatible with mkDerivation and other nixpkgs assumptions like the isPlatform checks and others I'm very suspicious of if that's actually well defined at all, there's some extremely tight coupling, especially with respect to the (imo) pretty evil stuff stdenv does with security hardening flags | 02:41:41 |
| Alexandros Liarokapis | In reply to @raitobezarius:matrix.org
Documenting a valid nixpkgs abiding stdenv is bound to be very complicated notably due to splicing constraints, etc. which are not even totally clear for experts This is a very good note, my main usecase currently is to use standard industry toolchains for cross building so keeping derivations compatible with the cross building infra is important. | 12:47:25 |
| Alexandros Liarokapis | Using such external toolchains is sometimes required due to them being IEC 61508 qualified. | 12:53:33 |
| Alexandros Liarokapis | Which allows them to be used in automotive and similar sectors, so it is good to have an escape hatch to use your own stdenv. Nix would be a great pitch for such sectors due to facilitating reproducible builds but this is kind of a game breaker because verifying compilers is expensive. | 12:57:07 |
| raitobezarius | If this is your usecases, I'd build various checks to ascertain that no non IEC 61508 component is used and fail the evaluation if so | 12:59:20 |
| raitobezarius | Then you can build your compliant stdenv | 12:59:27 |
