ghostty: allow darwin users to manager their config

[anund]

Description

Currently nixpkgs does not contain a package definition for ghostty compatible with Darwin. Darwin users may still want to use this module to manage their config or share config between systems. This carries over behaviour from the beta period where this same technique was used.

see: https://github.com/clo4/ghostty-hm-module/blob/887e13a6e7acf5ffaab0119d96e476d84db90904/module.nix#L167-L173

Also improves validation to cover theme files.

Requested via ghostty discord. Testing included building against a local copy of nixpkgs with the ghostty package deleted and marked as broken.

Checklist

• Change is backwards compatible.

• Code formatted with ./format.

• Code tested through nix-shell --pure tests -A run.all or nix develop --ignore-environment .#all using Flakes.

• Test cases updated/added. See example.

• Commit messages are formatted correctly

Maintainer CC

cc @HeitorAugustoLN

closes #6295

[rycee]

Seems like a duplicate of #6298?

[HeitorAugustoLN]

This is more complete than my PR in #6298. But i'd prefer to make things conditionally if the hostPlaform is darwin.
As @teto commented on #6298 (comment)

[anund]

I think default = null if the host is darwin might cover the user comment. Nullable was suggested for users managing config across multiple nixos/darwin systems as a ~least worst option.

[HeitorAugustoLN]

Here is how I think this should be handled:

[HeitorAugustoLN]

Just to capitalize ghostty in the description

Suggested change

	package = lib.mkPackageOption pkgs "ghostty" {
	nullable = true;
	extraDescription =
	"On darwin set this to null to manage ghostty config while ghostty is not present in nixpkgs.";
	};
	package = lib.mkPackageOption pkgs "Ghostty" { default = [ "ghostty" ]; };

[anund]

That doesn't appear to work when nixpkgs is marking the package as broken. Setting the package to null in config isn't allowed (not nullable) and nixpkgs evaluates the default since it is present. This does work when the package isn't present at all.

[HeitorAugustoLN]

It won't be present look at: #6300 (comment)

[anund]

Testing.

[anund]

Yup, my mistake on where the actual eval was coming from. "Ghostty" isn't needed if we're guarding all the package sites. mkPackageOption currently only checks for presence not whether or not the package is broken.

I considered checking if the package is broken instead and looked at ~hostPlatform. I think Linux is the only supported output from hostPlatform so that doesn't seem to buy much generality.

[anund]

Turns out this trying to avoid installing only on linux brings in different complications. When we just gate on isLinux we add a synchronization point with nixpkgs. If nixpkgs gains a darwin version of ghostty (as some are working on) this module will have to change at the ~same as it's introduced into nixpkgs. Addtionally, to a lesser degree, it also interferes with users ability to set their own package if they figure out some work around for themselves. If, say, a *bsd or darwin user gets a package working for themselves before it lands in nixpkgs they would not be able to use the module as is.

There's a bit of weirdness around a transition from broken -> working for macos users too. If a nixpkgs copy exists some users will want that copy and some will want the macos managed version instead. (technically this could also be the case for nix on Arch)

To me this suggests setting nullable: true and handling the null case. Trying to default to the 'right' value for darwin users runs into that point above around choosing darwin or nix hosted packages. My user facing suggestion for that is adding an assertion: (!lib.meta.availableOn stdenv.hostPlatform cfg.package) -> (cfg.package == null) with the message "programs.ghostty.package is marked as broken on your platform, set the value to null to manage your configuration without installing the package" While it's possible ghostty darwin becomes a package there isn't an easy option to avoid setting the package to null, as far as I can see.

[spikespaz]

Handling null for package is exactly the path I have chosen for my private Ghostty module. I support that route.

[spikespaz]

Perhaps allow setting ghosttyBinary with a default of /run/current-system/sw/bin/ghostty if isDarwin, and on linux use lib.getExe' "ghostty" cfg.package?

[mhanberg]

Should close #6295 (maybe edit the description with this so it auto closes my issue when this is merged 😃)

Thanks for this!