3 ms·

I'm kind of surprised this didn't link to the Nix RFC that considers changing the default builder from Bash to Oil: https://github.com/NixOS/rfcs/pull/99 https:

by Arcuru 4y ago

I'm kind of surprised this didn't link to the Nix RFC that considers changing the default builder from Bash to Oil: https://github.com/NixOS/rfcs/pull/99 https://github.com/NixOS/rfcs/pull/99 Of course it does have a different goal (of replacing Bash with OSH instead of only offering an alternative), but it has a lot of good discussion. Personally I think having alternative builders available is a great idea to improve the developer experience here.

ofchnofc 4y ago
[dead]
chubot 4y ago
(Oil author here) Thanks for mentioning it -- Oil is intended for exactly that kind of thing, in theory. That is, a clean shell language for gluing together distros, which are inherently heterogeneous and messy. In practice, I think there is limited time / resources / appetite for cleaning up a bunch of 15 year old bash, with the potential to break many things. Shell, and especially bash, can be very fragile. (I'm not speaking for the Nix team, I'd be interested their viewpoint) OSH runs many shell scripts unmodified, but not Nix's, even though we implemented many bash features that Nix uses. I mentioned that in the latest release: https://www.oilshell.org/blog/2023/03/release-0.14.2.html https://www.oilshell.org/blog/2023/03/release-0.14.2.html I'd still be interested in bug reports -- non-interactive language features tend to be prioritized, and are realistic --- So to "concede to reality", I think the approach of having new builders makes sense -- it's ADDING rather than REPLACING. It's sort of like what Rich Hickey says about functional programming -- you don't refactor your code, you just keep adding stuff. Having only used Nix a tiny bit, I didn't even realize new builders are possible. Is this the only other one? Is it possible to create some sort of "interface" for them? If there was a documented interface, maybe it will help people understand how to build packages, in addition to plugging in new builders. --- BTW for people wondering about the project, I just wrote a FAQ: Oils 2023 FAQ - https://www.oilshell.org/blog/2023/03/faq.html https://www.oilshell.org/blog/2023/03/faq.html tl;dr We're stabilizing OSH, the "good parts" that runs your existing scripts. In theory Nix could adopt this, with the harder "replacing" strategy. And we're renaming Oil to YSH to delineate the stable and unstable parts. YSH could be used with the "adding" strategy. Though the idea is that you can seamlessly upgrade from OSH and YSH, and not have two different things forever, but the costs/benefits are different for each project. And of course as I say, YSH isn't yet stable. (nushell is also pre - 1.0 from what I understand, but I guess version pinning helps with that.) Much more detail in the post. We can still use help :)
- pxc 4y ago
  > I didn't even realize new builders are possible. Is this the only other one? The Nix Pills is the document I'd look to to understand what a builder is in Nix: https://nixos.org/guides/nix-pills/working-derivation.html https://nixos.org/guides/nix-pills/working-derivation.html A builder is any program whose invocation is specified by a Nix derivation (think .drv file, specifically— not just any program that gets called in the course of a Nix build). Most packages in Nixpkgs are defined using the stdenv.mkDerivation function, which uses a bash builder. This is why a lot of the arguments used in package definitions are bash snippets. They get interpolated and sourced and otherwise woven together to make the bash scripts that run the actual builds. But for special purposes, it's not unusual to use builders in other languages, especially scripting languages, like Perl, Ruby, or Python. The first use case for special-purpose, non-bash builders that comes to mind for me is Nix code generation tools. When some enterprising Nixer writes a tool to partially or completely auto-generate Nix package definitions from the upstream packages native to their favorite language ecosystem, they often reach for that same language to do the job. This experiment and the Oil/Nix RFC are about creating another reusable/extensible, general purpose builder that could be used to build many packages, so that snippets in the new shell language could play a similar role to the current role of bash snippets in Nixpkgs. For some, the hope is that eventually such builders could replace the prevalent bash builders in Nixpkgs!

by Arcuru 4y ago

ofchnofc 4y ago

[dead]

chubot 4y ago

(Oil author here) Thanks for mentioning it -- Oil is intended for exactly that kind of thing, in theory. That is, a clean shell language for gluing together distros, which are inherently heterogeneous and messy. In practice, I think there is limited time / resources / appetite for cleaning up a bunch of 15 year old bash, with the potential to break many things. Shell, and especially bash, can be very fragile. (I'm not speaking for the Nix team, I'd be interested their viewpoint) OSH runs many shell scripts unmodified, but not Nix's, even though we implemented many bash features that Nix uses. I mentioned that in the latest release: https://www.oilshell.org/blog/2023/03/release-0.14.2.html https://www.oilshell.org/blog/2023/03/release-0.14.2.html I'd still be interested in bug reports -- non-interactive language features tend to be prioritized, and are realistic --- So to "concede to reality", I think the approach of having new builders makes sense -- it's ADDING rather than REPLACING. It's sort of like what Rich Hickey says about functional programming -- you don't refactor your code, you just keep adding stuff. Having only used Nix a tiny bit, I didn't even realize new builders are possible. Is this the only other one? Is it possible to create some sort of "interface" for them? If there was a documented interface, maybe it will help people understand how to build packages, in addition to plugging in new builders. --- BTW for people wondering about the project, I just wrote a FAQ: Oils 2023 FAQ - https://www.oilshell.org/blog/2023/03/faq.html https://www.oilshell.org/blog/2023/03/faq.html tl;dr We're stabilizing OSH, the "good parts" that runs your existing scripts. In theory Nix could adopt this, with the harder "replacing" strategy. And we're renaming Oil to YSH to delineate the stable and unstable parts. YSH could be used with the "adding" strategy. Though the idea is that you can seamlessly upgrade from OSH and YSH, and not have two different things forever, but the costs/benefits are different for each project. And of course as I say, YSH isn't yet stable. (nushell is also pre - 1.0 from what I understand, but I guess version pinning helps with that.) Much more detail in the post. We can still use help :)

pxc 4y ago
> I didn't even realize new builders are possible. Is this the only other one? The Nix Pills is the document I'd look to to understand what a builder is in Nix: https://nixos.org/guides/nix-pills/working-derivation.html https://nixos.org/guides/nix-pills/working-derivation.html A builder is any program whose invocation is specified by a Nix derivation (think .drv file, specifically— not just any program that gets called in the course of a Nix build). Most packages in Nixpkgs are defined using the stdenv.mkDerivation function, which uses a bash builder. This is why a lot of the arguments used in package definitions are bash snippets. They get interpolated and sourced and otherwise woven together to make the bash scripts that run the actual builds. But for special purposes, it's not unusual to use builders in other languages, especially scripting languages, like Perl, Ruby, or Python. The first use case for special-purpose, non-bash builders that comes to mind for me is Nix code generation tools. When some enterprising Nixer writes a tool to partially or completely auto-generate Nix package definitions from the upstream packages native to their favorite language ecosystem, they often reach for that same language to do the job. This experiment and the Oil/Nix RFC are about creating another reusable/extensible, general purpose builder that could be used to build many packages, so that snippets in the new shell language could play a similar role to the current role of bash snippets in Nixpkgs. For some, the hope is that eventually such builders could replace the prevalent bash builders in Nixpkgs!