| 29 Jul 2022 |
 profpatsch | I might do a little experiment with chez and see how it goes | 17:20:25 |
 infinisil | Other than bash sucking and us wanting to replace it with something better, are there any other motivations? | 17:21:00 |
 j-k | I thought the main problem with stdenv mkDerivation is how c & make centric it is | 17:21:32 |
| profpatsch | I don’t see a big reason for replacing bash tbh, I’d rather start by designing a replacement for the horrible phases abstraction | 17:21:35 |
| profpatsch | And the hook stuff | 17:21:46 |
| profpatsch | Which is next to impossible to grok, so all you can do is cargo-cult | 17:22:24 |
 Alyssa Ross | yeah, I don't think it's that important | 17:22:36 |
| Alyssa Ross | I think replacing it with OSH would be a good step, just because it'd be so easy | 17:22:51 |
| Alyssa Ross | And be an evolutionary improvement. | 17:22:57 |
| infinisil | I think bash is holding us back from doing improvements to phases and co. | 17:23:02 |
| profpatsch | although both might be coupled, because the phases thing is a natural extension of using lots of script interpolation | 17:23:03 |
| profpatsch | infinisil: weak agree | 17:23:15 |
| profpatsch | imo the first mistake was not using the fact that nix drvs are nix lists of argv | 17:23:48 |
| profpatsch | but, like, I don’t see how anything but incremental improvements can work, because the amount of code is so big and there’s next to no static analysis possible. | 17:25:22 |
| profpatsch | So OSH sounds like a good step, iff its performance is better or the same | 17:25:43 |
| profpatsch | I don’t have a strong will/desire to work on any of this tho (besides my own tiny experiments), so I will stop monologuing now :P | 17:26:48 |
| infinisil | Is the idea to use OSH-specific features to implement better phases and co. then? | 17:26:59 |
| Alyssa Ross | no, it's orthogonal | 17:30:07 |
| Alyssa Ross | the idea is to just have a better shell | 17:30:14 |
| j-k | would anything need to change with escapeShellArg need modification for oil? | 17:41:25 |
| j-k | * would anything with escapeShellArg need modification for oil? | 17:41:38 |
| Alyssa Ross | OSH is designed to be bash-compatible | 17:46:34 |
| Alyssa Ross | there's a whole RFC exploring this | 17:46:46 |
| infinisil | I'm asking myself the question why we care about a single language at all, couldn't we allow multiple? | 17:59:00 |
| infinisil | E.g. what if every phase (if that concept were kept) could be in its own language, and we'd have an interface for passing data between phase | 18:00:17 |
| infinisil | * E.g. what if every phase (if that concept were kept) could be in its own language, and we'd have an interface for passing data between phases | 18:00:19 |
 kevincox | I think for nixpkgs having a single language improves uniformity allowing any contributor to easily pick up and work on any packages. I like strong conventions.
That being said if we are adding new Nix primitives I would like to ensure that those are available to all languages for those who don't want to adopt nixpkgs conventions. | 18:00:25 |
| kevincox | In reply to @infinisil:matrix.org
E.g. what if every phase (if that concept were kept) could be in its own language, and we'd have an interface for passing data between phases This strikes me as likely to add far more complexity than value. | 18:00:56 |
| infinisil | Being able to easily contribute is a good argument | 18:01:48 |
| infinisil | I had one other use case in mind: Being able to easily extend phases (e.g. current hooks) in e.g. .overrideAttrs. This use case would work well with multiple languages | 18:02:56 |
