| 29 Jul 2022 |
 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 |
| infinisil | Alternatively: What if how derivations are built doesn't use any specific language at all. We'd essentially just have a Nix DSL for declaring what needs to be done. What language is used to implement this in the end doesn't matter and can be freely chosen | 18:03:57 |
| infinisil | That sounds very slow, but would be really good otherwise I think | 18:05:03 |
| infinisil | But then again, looking at most package definitions in nixpkgs, there's barely much bash-specifics in there | 18:06:53 |
| infinisil | Does it really matter that we have the features of language X to build packages, or are the features that we need so generic that any language could implement them? | 18:07:17 |
| profpatsch | infinisil: If we switched to e.g. chez scheme, I’d expect phases to be plain old functions, and then passing higher-order functions would become possible. | 18:12:34 |
| profpatsch | Which you don’t get when you e.g. serialize stuff to json or similar | 18:12:44 |
| infinisil | profpatsch: What use cases would benefit from this? | 18:14:30 |
| profpatsch | of course, the question is if you need that if you could also achieve it on the nix expression level. But then, how much would evaluation times suffer if we did that for every single derivation (that was one of the reasons there’s so much done in bash afaik) | 18:14:41 |
| profpatsch | infinisil: being able to pass functions back and forth is one of those order-of-magnitude improvements, the real question is what use-cases would not benefit from this | 18:15:38 |
