Packaging Ghostty for Flatpak/Flathub #3201
Replies: 11 comments 29 replies
-
|
This should be a discussion since there isn't a directly actionable result from this. 😄 |
Beta Was this translation helpful? Give feedback.
-
|
@mitchellh I think one thing that would be actionable is allowing the |
Beta Was this translation helpful? Give feedback.
-
|
My current workaround is to apply the following patch: diff --git a/build.zig b/build.zig
index b1b992fe..ff4c65b7 100644
--- a/build.zig
+++ b/build.zig
@@ -144,7 +144,7 @@ pub fn build(b: *std.Build) !void {
if (emit_bench or emit_test_exe or emit_helpgen) break :emit_docs false;
// We always emit docs in system package mode.
- if (system_package) break :emit_docs true;
+ // if (system_package) break :emit_docs true;
// We only default to true if we can find pandoc.
const path = Command.expandPath(b.allocator, "pandoc") catch |
Beta Was this translation helpful? Give feedback.
-
|
As an alternative solution, it might be deemed viable to host a custom repository (ideally on the Ghostty website) and allow users to install the repository with a flatpakref. |
Beta Was this translation helpful? Give feedback.
-
|
There is no point in packaging this as a Flatpak until Ghostty gets a solution like Ptyxis which runs an agent on the host. As far as I know, that does currently not exist. |
Beta Was this translation helpful? Give feedback.
-
|
@tristan957 Do you have any more information as to why an "agent" is necessary? |
Beta Was this translation helpful? Give feedback.
-
|
Nothing more than what is already mentioned. Happy to connect y'all with the author of Ptyxis to learn more. |
Beta Was this translation helpful? Give feedback.
-
|
@tristan957 What I mean is that neither your comment nor the mentioned link explain what this "agent" is and more importantly why it's needed. The equivalent of "Go talk to these people to find out" isn't really helpful. |
Beta Was this translation helpful? Give feedback.
-
|
Then please ignore and continue your process. Good luck! |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, “no point” is a bit of an overstatement. Other terminal emulators (e.g. Konsole, Blackbox) are packaged as Flatpaks with very permissive sandboxing and work fine. The host agent is mainly for integrating container/Flatpak management and foreground processes with the UI (see Prompt – Happenings in GNOME). A Ghostty Flatpak can certainly be useful without such an agent. Not to dogpile, just want to add context for anyone browsing who might think this effort is more blocked than it actually is :) |
Beta Was this translation helpful? Give feedback.
-
|
There appears to be another issue with using The way I can reproduce this is as follows: #!/usr/bin/env bash
set -e
VERSION=1.0.0
ARCHIVE=ghostty-source.tar.gz
wget "https://release.files.ghostty.org/${VERSION}/${ARCHIVE}"
tar -xf "${ARCHIVE}"
rm "${ARCHIVE}"
cd ghostty-source
ZIG_GLOBAL_CACHE_DIR=vendor ./nix/build-support/fetch-zig-cache.sh
zig build --system vendor/p |
Beta Was this translation helpful? Give feedback.
-
|
It seems this error is resolved when passing an absolute path to |
Beta Was this translation helpful? Give feedback.
-
|
I managed to get things to build, albeit in a way that's not suitable for Flathub:
The code for this proof of concept is found in https://github.com/yorickpeterse/ghostty-flatpak. To build, run the following: bash deps.sh
flatpak-builder --disable-rofiles-fuse --force-clean --user --install-deps-from=flathub --repo=repo --install builddir org.ghostty.ghostty.ymlThe |
Beta Was this translation helpful? Give feedback.
-
Similar tools exist for other languages here, but unfortunately zig does not yet have one. It might be helpful to see how it's done in other languages and write a similar tool for zig? |
Beta Was this translation helpful? Give feedback.
-
|
There's zig2nix. It can produce a JSON file that looks like this: |
Beta Was this translation helpful? Give feedback.
-
|
This looks very close to what flatpak manifest files expect. Some formatting should make the script usable for flatpaks. e.g. this is an autogenerated rust dependency |
Beta Was this translation helpful? Give feedback.
-
|
Building from source is not a hard requirement on Flathub, especially if there are tooling issues. You could just repackage existing binaries and call it a day |
Beta Was this translation helpful? Give feedback.
-
|
@jcollie Said tool has been suggested in Discord as well, but I haven't looked into it yet deeply. I don't use Nix though, and from the README it wasn't clear how to build it without Nix. @faveoled Packaging an existing executable can introduce issues, such as the executable only working on a specific platform (e.g. x86-64) or simply not working any more at some point in the future due to some other change. As such, it's best to build from source with all the right dependencies and what not included, otherwise long term maintenance becomes a challenge. |
Beta Was this translation helpful? Give feedback.
-
|
There seems to already be a manifest and Flatpak integration in the repo, but it's a bit broken and no longer builds: |
Beta Was this translation helpful? Give feedback.
-
|
For those interested in Flatpak/Flathub support, this is currently blocked by #3616. Help with said issue would be greatly appreciated 😃 |
Beta Was this translation helpful? Give feedback.
-
|
While I like to chime in on having a Flatpak, I also want to point to notes from another terminal emulator that recommends native packaging over Flatpak: https://wezfurlong.org/wezterm/install/linux.html?h=flatpak#installing-on-linux-via-flathub |
Beta Was this translation helpful? Give feedback.
-
|
I had my suspicions about this as well. It's nice for sandboxing electron/similar apps, for example slack or discord, however I found that for example installing vscode via flatpak is quite a fool's errand for the reasons stated, especially as an extension developer. I agree with the reasoning - as you gain the trustworthiness of the new emulator, upgrade to native packaging |
Beta Was this translation helpful? Give feedback.
-
|
Natively installed terminal apps like Btop don't open from the app launcher when I have Ptyxis as a flatpak. |
Beta Was this translation helpful? Give feedback.
-
|
dont know if this might help, but you could download all dependencies before the build starts. I did the same here for prusa slicer: https://github.com/flathub/com.prusa3d.PrusaSlicer/blob/d32b6e63bb7b6b690ac40749d462898c62a6d141/com.prusa3d.PrusaSlicer.yml#L97 |
Beta Was this translation helpful? Give feedback.
-
|
The NixOS Ghostty package is already using |
Beta Was this translation helpful? Give feedback.
-
|
The absolute paths do not work in nix sandbox either way, so I should probably remove the support. I notice lots of nixpkgs packages and projects such as zls using only the zon2nix part of zig2nix, I think that's fine and I don't intend to break that use case. I'll see if I can make it output the proper formatting as well to reduce the manual steps. |
Beta Was this translation helpful? Give feedback.
-
|
@Cloudef The zon2json tool looks like it would be incredibly useful. I'll give it a try to see if this is something we can use for building a Flatpak package 😃 |
Beta Was this translation helpful? Give feedback.
-
|
I spent some time playing around with the zon2json tool, and built a PoC to use that to generate Flatpak sources. While it sort of works, it doesn't quite handle recursive dependencies and after several hours I decided it was enough. My current plan is to build a |
Beta Was this translation helpful? Give feedback.
-
|
You can copy the bash script block from https://github.com/Cloudef/zig2nix/blob/master/tools/zon2json-lock.nix which will handle recursive deps. You have to replace the nix based hashing commands though. |
Beta Was this translation helpful? Give feedback.
-
|
https://github.com/yorickpeterse/ghostty-flatpak is now in a sort of OK state. That is, we pre-build an archive containing the dependencies and then host that using a GitHub release. It's a bit of a hack, but it's the most reliable way of providing the dependencies such that we can use this for a future Flathub package. Unfortunately, the resulting Flatpak application isn't terribly useful. Due to the Flatpak integration being broken, the application runs in its own environment. While it does have access to the file system, it won't be able to properly run host executables as various directories in As such, there's no point in submitting the package to Flathub at this stage. Thus, until the linked issue is resolved there's nothing more I can do. |
Beta Was this translation helpful? Give feedback.
-
|
@lihaohong6 I played with On the other hand, entering a Toolbox container does appear to work: Per flatpak/flatpak#3285 host-spawn might indeed be an option, but having to install yet another tool isn't great. |
Beta Was this translation helpful? Give feedback.
-
|
@yorickpeterse I checked Wezterm's solution and they are using |
Beta Was this translation helpful? Give feedback.
-
|
@lihaohong6 While I appreciate the suggestion, the real solution here is for people to look into this issue and figure out why the Flatpak integration is broken. Applying various workarounds when there's already an integration present is just silly. |
Beta Was this translation helpful? Give feedback.
-
|
It might be easier to use The main reason is that Ghostty terminal subprocess handling is tightly coupled to |
Beta Was this translation helpful? Give feedback.
-
|
@alaviss If this is integrated into Ghostty itself then that would indeed be fine (i.e. all commands just get wrapped in What I meant with my original comment (which in hindsight I didn't make clear enough) was that somehow patching the Flatpak to use |
Beta Was this translation helpful? Give feedback.
-
I'm working on packaging Ghostty for Flatpak/Flathub. This brings some challenges with it, such as Flathub not allowing network access during the build process. The packaging guidelines outline some steps to take to build from a local package cache. Unfortunately, this introduces the following problems:
zig build --systemthe-Demit-docsoption is implied. This is unnecessary for Flatpak but results in build errors because Pandoc isn't installed in the sandboxFor problem one I created the following script to remove large redundant directories (e.g. some dependencies include 40 MiB worth of screenshots or 50 MiB test directories):
rm -rf vendor/p/*/{test,Test,screenshots,result,doc,data}This isn't ideal, but it ends up cutting the directory/archive size in half, though the resulting 200 MiB is still too large to include directly into a repository somewhere (and Flatpak doesn't support Git LFS for build sources). Ideally Ghostty release provide an archive containing just the dependencies such that this can be added as an extra dependency.
For problem two it appears there's no sensible solution right now. Probably the best option is to allow
-Demit-docs=falseto override the default implied by--system.Current state
I've set up https://github.com/yorickpeterse/ghostty-flatpak which contains a proof of concept. The build process isn't suitable for Flathub because it requires network access, but it at least produces what appears to be a working Flatpak for Ghostty. To make this suitable for Flathub, Ghostty needs to properly support offline builds which currently isn't the case, and the dependencies need to be published somewhere such that they can be downloaded during the build process.
See #3201 (comment) for more details.
Related issues
Beta Was this translation helpful? Give feedback.
All reactions