Rewrite it in Python

[iFreilicht]

Problem

Disko is currently somewhat tricky to maintain. Part of this comes from the current architecture that puts nix itself at the center of the entire operation, and uses it as a crude templating engine for bash scripts.

This makes implementation of some features difficult. A few examples (I'll add more when I come across them):

• Read current disk and output to disk-config.nix #728
• Feature Request: Add confirmation option for each disk when running script #772
• ZFS Features Support: Dataset property inheritance #560
• Refuse to evaluate if zpool is set to mirror if only one device is given #645
• Random boot failues due to partition confusion because disko now relies on by-partlabel #551
• Ignore Partitions #533
• [Feature request] Changing disk without reevaluation #732

Proposed solution

Switch to a different architecture where the nix files only define configuration values, and a bigger program written in a proper language (not bash or perl) runs nix eval --json and works with the JSON output to plan and execute all the required actions.

Considerations

Compatibility

The interface for users should not change at all. disko.devices should have the exact same type and result in the same configuration values as before.

Some programs (most notable nixos-anywhere, AFAIK) use disko's diskoScript output and call this script directly. Because this is a derivation, it should be possible to just swap them out no matter the language, as long as the resulting path has a binary with the same name. However, a simple shim with a single-line script that just calls the CLI with the required flags might be sufficient for this.

Language to use

The language should make it easy for others to contribute, have decent error-handling capabilities and be well-suited to write a CLI in.

I am therefore immediately discarding bash (or any other shell language), perl, JS, TS and Haskell.

I see three main contenders: python, rust, and go. They are all well-known and have good general support. Rust is additionally loved in the nix community for its ethos of correctness, python is super easy to write, and go is kind-of a middle-ground between the two.

One thing to consider with this choice might be closure size. As disko is often run in installers, we can expect most dependencies to not be present yet (this is the singular advantage of bash; it is guaranteed to already be present). The closure sizes of the main executable vary quite a bit:

$ nix path-info --closure-size -h nixpkgs#cargo^out
/nix/store/j6vpbh78ngj2x7jrg27pqjn2cd5mzywl-cargo-1.79.0          1.2G
$ nix path-info --closure-size -h nixpkgs#go^out                                                                                                                                                                                                                                                                                          
/nix/store/kqf4gwhq1yrchvmvqjh4adc4y9hxp9xk-go-1.22.5    248.0M
$ nix path-info --closure-size -h nixpkgs#python3^out                                                                                                                                                                                                                                                                                    
/nix/store/l014xp1qxdl6gim3zc0jv3mpxhbp346s-python3-3.12.4       166.1M

It seems somewhat unreasonable to me to require the user to download 1.2 gigabytes just to be able to run disko. A binary cache could alleviate this, though this has additional usability implications.

In the case of rust and go, there would also be compilation times added, though it's hard to say if this will matter much given the size of this project.

In general, I don't yet have a strong preference for which language to use.

[Mic92]

With nixos-anywhere we need to be able to build disko from source in a memory constraint environment. Currently our kexec image targets 1GB of RAM memory usage. We cannot depend on a binary cache just now because disko is not part of nixpkgs and the disko configuration is derived from the module system. We do have a dependency of python in the installer. We almost got rid of perl because of the perlless profile except for nixos-generate-config.

As see just now is that both the go and rust compiler might be almost as large as our kexec image (also this is compressed).

[Mic92]

One nice property of bash besides the really bad error handling is that its execution is very easy to introspect with set -x. So I think whatever replaces the bash code should be also be easy to debug at runtime.

[Lassulus]

also a problem of the rewrite is, that we can only rewrite the creation and mounting, the nixos configuration has still to be generated in the module system, so we would have two parallel implementations of the disko code.

[Mic92]

I don't follow this logic. We already have _create and _mount in bash so there is already a second imperative implementation next to the NixOS configuration.

[Lassulus]

yes, but instead of templating bash we would be templating rust, python or go code?

[iFreilicht]

@Mic92 that's very useful information, thank you! That makes it seem like python is the only viable option.

We do have a dependency of python in the installer.

Which installer? I booted a NixOS ISO and didn't see python in there, but I assume you're talking about something else?

also a problem of the rewrite is, that we can only rewrite the creation and mounting, the nixos configuration has still to be generated in the module system, so we would have two parallel implementations of the disko code.

This is not a problem, it's just a different way of modelling the problem space. Of course, we have to avoid duplicate implementations. If a value is required by both the nixos configuration and the mount/format code, its value must be computed in nix code. But there's no need for all the logic that actually creates partitions and mounts them to be implemented as templated bash, we can choose to implement them however we want.

yes, but instead of templating bash we would be templating rust, python or go code?

No, not at all. My goal is is remove all _create and _mount attributes. Python code is awfully tricky to template because it's indentation dependent. Go or Rust might be simpler in that regard, but it's still a bad solution. Instead, the create/mount code would shell out to nix, evaluate the configuration as a JSON and then use that as an input.

It's true that we would have to change the structure a little, so next to zfs_fs.nix, zfs.nix and zpool.nix there would be a zfs.py file, but I don't see how that's an issue.

One nice property of bash besides the really bad error handling is that its execution is very easy to introspect with set -x. So I think whatever replaces the bash code should be also be easy to debug at runtime.

Very true! Well wouldn't you know it, python allows you to do exactly that with the trace module.
Though I think it would also be fine to just do meticulous logging. In the past, I've just written a short wrapper around the exec primitive of the language to logged all inputs and outputs on any shell command invocation.

[Mic92]

Which installer? I booted a NixOS ISO and didn't see python in there, but I assume you're talking about something else?

Afaik it's used for systemd-boot installer, but it's not in $PATH - which might be a problem for disko actually. However we have it in our kexec image for sure for restoring network configuration.

yes, but instead of templating bash we would be templating rust, python or go code?

I wouldn't use templating at all. I would parse json instead and generate a plan based on that.
Json could be also used to inject package dependencies.

[Mic92]

However overall it might be quite ambiguous to re-write a 3k LOC project written in a terse language in one go. I would suggest if you want to go this route is to replace one smaller module with some prototype so we can see if this goes in the direction we are all happy with.

[sedlund]

nushell is an interesting option for this use case. it has much better error handling and debugging, and is meant to easily interop with existing shell tools that are heavily used in disko.

[iFreilicht]

That's an interesting idea. It's been a few years since I had a look at nushell. I'll read up on it. I also considered xonsh, it has a similar advantage of allowing easy interop with shell tools while working with resulting values in the python world.

How well is nushell suited to building CLIs in your opinion?

[phaer]

How would nushell compare to pythonMinimal in terms of file size? The binary release sizes at https://github.com/nushell/nushell/releases seem to suggest they might be in the same ballpark? .

[Yethal]

+1 to nushell. Much better handling of structured data, easy interoperability and few if any footguns compared to bash
Plus it natively supports structured formats like json,yaml,toml etc so the 'generate json plan and feed it to external program' approach is feasible

[mmlb]

I'd throw elvish into the mix too. I haven't played around with nushell but I've started to convert all my scripts to elvish mainly because of the much better/enforced error handling. Its like what everyone expects from bash's set -euo pipefail but correct.