| 4 Jul 2025 |
 sterni | i think gnatprove was blocking gnat14, but I think it has been fixed or there’s a PR for it | 15:03:16 |
| 5 Jul 2025 |
 9lore | In reply to @sternenseemann:systemli.org
i think gnatprove was blocking gnat14, but I think it has been fixed or there’s a PR for it merged in may: https://github.com/NixOS/nixpkgs/pull/407720 | 18:04:01 |
 alexfmpe | huh what's the difference between, say, *.hostPlatform and *.stdenv.hostPlatform | 22:06:32 |
 Tristan Ross | In reply to @alexfmpe:matrix.org
huh what's the difference between, say, *.hostPlatform and *.stdenv.hostPlatform It's an alias pretty much so it's literally the same thing | 22:10:43 |
| Tristan Ross | It's always recommended to use the one in stdenv | 22:11:13 |
| 7 Jul 2025 |
|  nbp changed their display name from nbp — PTO to nbp. | 13:11:49 |
| 9 Jul 2025 |
|  atagen joined the room. | 07:51:18 |
| 13 Jul 2025 |
|  timschumi joined the room. | 18:29:15 |
| 17 Jul 2025 |
 Grimmauld (any/all) | https://github.com/NixOS/nixpkgs/pull/425246
What di i need to do to make sure this doesn't break stdenv due to fetchpatch2 usage? | 09:04:24 |
| Grimmauld (any/all) | * https://github.com/NixOS/nixpkgs/pull/425246
What do i need to do to make sure this doesn't break stdenv due to fetchpatch2 usage? | 09:04:28 |
 K900 | Build stdenv? | 09:07:26 |
| Grimmauld (any/all) | do i actually have to build it, or is an eval enough? | 09:08:59 |
| K900 | Eval is enough | 09:09:05 |
| 21 Jul 2025 |
 connor (he/him) (UTC-7) | Hey all — what can be done in the interest of improving setup.sh, along the lines of https://github.com/NixOS/nixpkgs/pull/385960#discussion_r2094198547? Would it be reasonable to introduce a standard library of sorts for setup.sh to better separate the core logic of the stdenv phases from utility functions they need along the way?
In particular, I’d hope that such a solution would allow for re-use of helpful functions outside of stdenv (for example, when writing small bash scripts) and a way to write test suites for the various functions. (And in time, the various components of setup.sh.) | 14:32:31 |
 emily | ideally we make structured attributes unconditional so we need less conditioning on that kind of thing to begin with :P | 14:35:00 |
| emily | splitting up setup.sh might be a good idea | 14:35:13 |
| emily | I don't know if there'd be that much use for the library outside of stdenv though | 14:35:31 |
| emily | (if you write a Bash script and it needs a library function, you should write a Python script instead) | 14:35:45 |
| connor (he/him) (UTC-7) | Python’s a whole thing though — sometimes I want to execute a bunch of python scripts in a directory in serial and accumulate exit codes | 14:38:42 |
| connor (he/him) (UTC-7) | Actually that’s not as strong of a rebuttal as I thought it was, I concede lmao | 14:39:02 |
| emily | that can be a Python script calling Python functions :) but sure, I'm not saying Bash has 0 utility. but if you start doing type checks in it it becomes time to reconsider | 14:39:23 |
| emily | like hopefully more hooks etc. can be Python in future even | 14:39:33 |
| emily | there's an open PR to get python3Minimal to 0 deps so we can use it freely for build stuff | 14:39:53 |
| connor (he/him) (UTC-7) | I guess this might have been cleaner as a Python script: https://github.com/NixOS/nixpkgs/blob/9967bf134c435416240b80b206b36fd5fff0d6b1/pkgs/development/libraries/science/math/magma/generic.nix#L235 | 14:40:32 |
| emily | I think this isn't horrible, but it's at about the maximum Bash I can stomach before I start wishing it wasn't | 14:41:45 |
 Alexandros Liarokapis | I wonder if an a main model object for each package like https://docs.conan.io/2/reference/conanfile/methods/package_info.html#cpp-info-library-and-build-information would be useful. Then stdenv hooks would modify the model, not the flags directly. This among other things allows for cflags deduplication in contrast to the adhoc approach of just appending strings like currently. Conan is having great success producing build-tool specific integrations as well by also keeping build-tool-specific metadata for each package and having a unified model for each build tool. Helps avoid gcc wrappers etc. | 22:12:35 |
 Randy Eckenrode | That sounds like something I suggested a while back where packages would have a build-system, which would modify the derivation with whatever configuration it needs. | 23:57:53 |
| Randy Eckenrode | However, it seems that hooks written in Bash seem to be the preferred way of doing things. | 23:58:21 |
| 27 Jul 2025 |
 John Ericson | ah GCC's spec files are at least morally similar | 16:36:03 |
| John Ericson | yeah, I like the idea of paying to make everything doable with spec files and these config files along | 16:36:22 |
