| 2 Aug 2022 |
 j-k | My only worry is everyone accepts bash, g | 12:00:01 |
| j-k | * https://github.com/bats-core/bats-core | 12:00:13 |
 infinisil | Neat! We should consider this as an option too | 12:01:10 |
| j-k | My main worry with having the lowest level of nixpkgs, and similarly the rest of nixpkgs, using something other than bash is bash is well accepted, getting people to be happy with a different tool can be extra onboarding friction | 12:01:25 |
| infinisil | I believe most users won't have to interact with bash directly | 12:02:21 |
| infinisil | An estimated 95% of packages don't rely on bash-specifics | 12:02:45 |
| infinisil | As in, the packages Nix expression | 12:03:00 |
| j-k | it's not about interaction, its about tool ingestion. People are finally cluing up on supply-chain security and actually reviewing they programs they depend on | 12:03:20 |
| infinisil | Does bash have an advantage there? | 12:04:21 |
| infinisil | E.g. one of the alternatives that has been considered is Lua | 12:04:43 |
| j-k | I don't think there's a single organization on the planet that would have to go out of their way to approve bash. everyone accepts it as a dependency of something | 12:05:11 |
| infinisil | You do have a point there | 12:05:54 |
| j-k | currently you'd just need to say, "we need to onboard nix, the rest is likely onboarded: stdenv tools which are pretty standard everywhere (core-utils, gcc), fetchers that use git & curl". Adding in 1 extra odity is probably not a big blocker but it is another blocker | 12:08:03 |
| infinisil | Though bash is very easy to write insecurely, which makes me think that companies should be more willing to accept a safer language | 12:08:27 |
 Melkor333 | I would so want to recommend oil shell (which tries very hard to be a sane upgrade path) but that would get us back to the security chain problem | 12:09:20 |
| Melkor333 | *upgrade path from bash | 12:09:33 |
 Alyssa Ross | I think trying to optimise for box ticking by hypothetical companies is not going to be productive | 12:09:44 |
| j-k | is it hypothetical if some of the clients I consult for are actually like this? | 12:10:30 |
| infinisil | Actually we don't really need to be worried about that very much, since nix runs in a sandbox anyways | 12:10:41 |
| infinisil | * Actually we don't really need to be worried about that very much, since nix runs builders in a sandbox anyways | 12:11:18 |
| j-k | you can't just run anything you want in a sandbox because you care about the output | 12:11:45 |
| Alyssa Ross | (IMO it's also very unlikely the Nix sandbox would stand up to truly malicious code) | 12:12:10 |
| infinisil | In reply to @j-k:matrix.org
you can't just run anything you want in a sandbox because you care about the output Ah right.. | 12:12:37 |
| Alyssa Ross | let me revise my statement then, since the companies are not hypothetical | 12:14:38 |
| Alyssa Ross | I think trying to optimise for box ticking is not going to be productive | 12:14:44 |
| infinisil | Hehe | 12:15:08 |
| infinisil | We do need to keep that in mind, but yes I don't think this is a blocker at all for using something other than bash | 12:15:33 |
| Alyssa Ross | If we can deliver more value by using a better tool, we can presumably justify that tool | 12:16:01 |
| j-k | yes we can totally go for oil if it adds significant value. it doesn't look like oil itself has many dependencies either. just something to consider | 12:16:16 |
| Alyssa Ross | One thing you might find quite alarming about Oil is that it has a self-maintained Python 2 fork! | 12:16:37 |
