| 17 Jul 2025 |
 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 |
| John Ericson | mmmm very good | 16:36:23 |
| emily | it does mean that we can no longer solve problems in wrappers at all and have to pay the costs of contributing to drivers for anything we end up needing | 16:42:47 |
| emily | which is a bit painful | 16:42:49 |
| emily | e.g. I am adding -fmacro-prefix-map to cc-wrapper right now | 16:43:01 |
| emily | figuring out how LLVM would want a "map away all hashes in the Nix store for __FILE__" feature to look would be substantially higher-cost/longer-time | 16:43:19 |
| John Ericson | emily: well we don' | 16:51:52 |
| John Ericson | * emily: well we don't have to do 100% one or the oher | 16:51:59 |
| John Ericson | * emily: well we don't have to do 100% one or the other | 16:52:01 |
| emily | most of the benefits only happen when you 100% eliminate wrappers | 16:53:00 |
| emily | e.g. libclang used by Rust bindgen | 16:53:05 |
| emily | is inherently working with an "unwrapped compiler" and this causes issues | 16:53:13 |
