feat(home-manager): add support for ghostty #446
Conversation
|
Hi, is there any reason this PR was closed? Or if the author is no longer interested in implementing it, is it okay to make a new PR adding this module? |
Seemed like I was getting the runaround a bit on this without any real conversation happening to tell me why and I lost interest. I’d be happy to pick this back up if a clear direction can be provided, I’m just not sure what to do with two reviewers asking for conflicting changes. No hard feelings or anything, because text tends to present negatively. |
|
We're sorry about that, genuinely There have been a lot of large refactors recently, and its made us change the approach we use in applying ports to different programs. I'll admit I'm the one who pushed a lot of these changes, and I'm more familiar with the effects they have than @isabelroses. I should have communicated these better, as well as some of the new things to look out for; that's my bad The issue that caused this difference in review -- Import from Derivation -- is one that has been a pretty hot topic recently, and it's no doubt because of this. I plan on writing an explainer in our docs so others aren't blind sided by this again, as it's not exactly easy to catch I'd love to see this continued, and I'll make sure to answer any questions along the way |
|
All right, well I appreciate the context. Can you point out a port that is up to date that I can reference? I started with copying the kitty config (thinking it would make the port simple lol). |
|
@getchoo I think I've resolved all the requests above. |
| let | ||
| inherit (config.catppuccin) sources; | ||
|
|
||
| cfg = config.catppuccin.ghostty; |
There was a problem hiding this comment.
| cfg = config.catppuccin.ghostty; | |
| cfg = config.catppuccin.ghostty; | |
| enable = cfg.enable && programs.ghostty.enable; |
Since we're also placing a file in ~/.config with xdg.configFile, we should make sure that is only done when Ghostty itself is enabled (just like the values of programs.ghostty.settings only being written to its config file when its enabled)
modules/home-manager/ghostty.nix
Outdated
| { | ||
| options.catppuccin.ghostty = catppuccinLib.mkCatppuccinOption { name = "ghostty"; }; | ||
|
|
||
| config = lib.mkIf cfg.enable { |
There was a problem hiding this comment.
| config = lib.mkIf cfg.enable { | |
| config = lib.mkIf enable { |
And the way we usually do that is just by guarding all of our changes behind that condition
There was a problem hiding this comment.
I want to confirm this one, because I actually had that implemented as you suggest and was told it was unnecessary here: #446 (comment)
There was a problem hiding this comment.
At that revision the comment was correct due to the module only touching programs.ghostty options
Those are already only applied when programs.ghostty.enable is true. When we touch options outside of it (in this case xdg.configFile) though, we need to implement that same guard internally (else we may end up placing port files on people's systems for programs they're not actually using)
Honestly, I think this is already a great example of how we want these modules to be handled now 😆 But for the future, some of my favorites are With k9s and btop being the most similar to this one The general idea is to place our port sources at the right path (or list exactly where they are) so that the program can read that at runtime. This is opposed to us reading these files at evaluation time in the modules to set options like |
Fixes #427