Add Flatpak build system and support

[someone13574]

ping #6687

This is the third iteration of this PR (v2 here) and uses a different approach to the first two (the process wrapper lib was a maintainability nightmare). While the first two attempted to spawn the necessary processes using flatpak-spawn and host-spawn from the app inside the sandbox, this version first spawns the cli binary which then restart's itself outside of the sandbox using flatpak-spawn. The restarted cli process than can call the bundled app binary normally, with no need for flatpak-spawn because it is already outside of the sandbox. This is done instead of keeping the cli in the sandbox because ipc becomes very difficult and broken when trying to do it across the sandbox.

Gnome software (example using nightly channel and release notes generated using the script):

TODO in this PR:

• Bundle libs.
• Cleanup release note converter.

Future work:

• Auto-update dialog
• Flatpak auto-update (complete 'Auto-update dialog' first)
• Experimental bundle releases for feedback (?).

(?) = Maybe / Request for feedback

Release Notes:

• N/A

[versecafe]

Figure out how to deal with release-information. (flathub doesn't like long release notes; zed's release notes are pretty long).

You could try doing some simple automated summary of the release notes through something like OpenAI's API it shouldn't hallucinate with text summarization, but there is a small risk and it could drop some of the more important changes or focus on minor ones sometimes, but I don't know how else you'd automate it without eiter just trimming after x chars or having separate release summaries for flatpack.

[bbb651]

Maybe sorting based on the likes of the linked github issues it closes, then show the top 5 and link to the full release notes at the end? It’s unreasonable to shrink 30+ bullet points into 3 sentences without it being a word soup or completely skipping all of the details, ai isn’t magic.
I checked what other large apps like browsers, vscode, lapce, discord, etc. (I know some of them aren’t official) - turns out all of them just have no release notes, so doing this seems to more than enough, it’s very unreasonable to ask large apps to provide 3 sentence release notes.

[someone13574]

Maybe sorting based on the likes of the linked github issues it closes, then show the top 5 and link to the full release notes at the end?

For larger releases, avoid endless bullet point lists and rather go with a few paragraphs or a shorter summarized list instead

Seems like that is allowed.

link to the full release notes at the end?

We already have the <url> tag which does that.

[mikayla-maki]

We appreciate the feedback @ryanabx, but let’s put that in the flatpak issue: #6687

[yodatak]

Before that run script/generate-licenses

[yodatak]

Sorry to bother with it but when i try to edit a single file with gui in gnome zed devel is not listed , i cannot find witch portal we need for that xdg-desktop-portal

[someone13574]

@yodatak

Sorry to bother with it but when i try to edit a single file with gui in gnome zed devel is not listed , i cannot find witch portal we need for that xdg-desktop-portal

I think that’s because the mimetype list in the desktop file is very small atm. I was trying to keep the changes small since that’s a bit of a side tangent to this PR, but I’d be happy to add some more in a different PR.

[ConradIrwin]

I've merged this for now. Thanks for pushing this over the line @someone13574

In terms of next steps:

• Over the next few weeks we're pushing towards a first preview release of Linux. This will not be flatpak based, but will use the curl https://zed.dev/install.sh | bash installer instead.
• It is not currently a priority for us to keep pushing on the flatpak work. That said, if we can get listed on flat hub without any more code changes, I'd be happy to help out with that effort as needed.
• We are not going to make changes to interact with bespoke sandboxes for the foreseeable future – our first priority has to be a non-sandboxed linux install that works well. If you would like to run zed in a sandbox, you are welcome to do so, but we're unlikely to prioritize issues if stuff doesn't work because of that.

[RustoMCSpit]

has this been mentioned? flathub/flathub#5253 this is the draft in flathub for zed

[someone13574]

has this been mentioned? flathub/flathub#5253 this is the draft in flathub for zed

Yes, its been mentioned but will likely never go anywhere due to how we are doing flatpak on Zed's end (escaping the sandbox and rebundling the normal linux binary).

[RustoMCSpit]

Yes, its been mentioned but will likely never go anywhere due to how we are doing flatpak on Zed's end (escaping the sandbox and rebundling the normal linux binary).

oh i see, well i mean would that break its ability to be toggled with something like flatseal?

[ryanabx]

Yes, its been mentioned but will likely never go anywhere due to how we are doing flatpak on Zed's end (escaping the sandbox and rebundling the normal linux binary).

oh i see, well i mean would that break its ability to be toggled with something like flatseal?

Yes. If I understand correctly the permission that makes it all work is talk-name=org.freedesktop.Flatpak which is needed for flatpak-spawn --host

[RustoMCSpit]

okay great, so why does the sandbox need to be escaped?

[ryanabx]

okay great, so why does the sandbox need to be escaped?

Because unless you're using containers for development, you'll want access to development resources (i.e. language support packages, language servers, etc.) outside the sandbox, and will want to run commands outside the sandbox

[jtolio]

Because unless you're using containers for development, you'll want access to development resources (i.e. language support packages, language servers, etc.) outside the sandbox, and will want to run commands outside the sandbox

I got the impression that these were things zed automatically downloaded and installed. I certainly would much prefer all of these things running inside the sandbox rather than outside?

[3lpsy]

For those interested in at least launching Zed in Flatpak w/out the sandbox escape (org.freedesktop.Flatpak Talk permission), you can set the the env var ZED_FLATPAK_NO_ESCAPE=1. Relevant code here:

zed/crates/cli/src/main.rs

Lines 411 to 414 in 74e25c1

	fn get_flatpak_dir() -> Option<PathBuf> {
	if env::var(NO_ESCAPE_ENV_NAME).is_ok() {
	return None;
	}

Seems like the sandbox escape is used to get an install directory. With the env set, I believe it works. Pywrite (default python lsp) seems to work and I was able to install an extension (Ruff) which also seems to work. I'm sure something will break eventually but seems usable at the moment. Also possible I'm missing something as I was surprised it worked.

[someone13574]

For those interested in at least launching Zed in Flatpak w/out the sandbox escape (org.freedesktop.Flatpak Talk permission), you can set the the env var ZED_FLATPAK_NO_ESCAPE=1. Relevant code here:

zed/crates/cli/src/main.rs

Lines 411 to 414 in 74e25c1

	fn get_flatpak_dir() -> Option<PathBuf> {
	if env::var(NO_ESCAPE_ENV_NAME).is_ok() {
	return None;
	}

Seems like the sandbox escape is used to get an install directory. With the env set, I believe it works. Pywrite (default python lsp) seems to work and I was able to install an extension (Ruff) which also seems to work. I'm sure something will break eventually but seems usable at the moment. Also possible I'm missing something as I was surprised it worked.

We've given the sandbox the permissions it needs for most features to function correctly inside the sandbox without modifying Zed's source. The main thing which will be broken is the terminal, as it will be spawned inside the sandbox which kind of cripples it. Git blame and dev extensions will also be broken iirc.

The implementation could probably be redone so that it doesn't do the full sandbox escape, but that would take time and effort which I don't have at the moment. If somebody was to go down that root I would recommend implementing it alongside the sandbox escape method to begin with and then removing the sandbox escape method once it has been tested for a while (I'm sure that there are other things broken which aren't immediately obvious).

[PgBiel]

Seems like the sandbox escape is used to get an install directory. With the env set, I believe it works. Pywrite (default python lsp) seems to work and I was able to install an extension (Ruff) which also seems to work. I'm sure something will break eventually but seems usable at the moment. Also possible I'm missing something as I was surprised it worked.

Hey @3lpsy, I've been using fully sandboxed Zed for several months now, and it very much works for all my needs! If you'd like, I can try to eventually put together some more detailed instructions (or even try to create a proper Flatpak manifest for this somehow), but for the moment, also considering that this PR probably isn't the best place for discussion (#6687 would be more appropriate, although it was closed so I'm not 100% sure), here's a not-so-short summary:

1. I'm not using the official Zed Flatpak, but rather running the official Zed executable inside another app's sandbox, in particular VSCodium as it's also an editor and so it uses a good runtime for it (org.freedesktop.Sdk). This probably isn't a strict requirement, however (I just began using my setup before this PR was merged)
2. Here's how I use each language (in language servers, the terminal etc.):
   • Python, C/C++ (GCC): I believe they come built-in with org.freedesktop.Sdk, nothing to do.
   • Rust, Dotnet (C#, F#, ...), Node.js, Zig: I have their respective flatpak Sdk extensions installed¹²³⁴. There's also an SDK for Java (OpenJDK)⁵.
     • Zed automatically installs any missing language servers, so even if some extensions don't include directly accessible language servers, Zed works fine.
     • Note that if you don't share your home folder, changes to certain non-XDG-compliant cache directories, like ~/.cargo and ~/.dotnet, won't persist between app runs; you have to explicitly add those directories under "Persistent directories" in Flatseal to fix that.
3. For anything else, including not only languages not listed above (such as Idris, Roc and so on) but also project-specific libraries I need (e.g. graphics stuff like X11 and wayland dev libraries), I just use direnv⁶ to spawn an environment from a Nix shell⁷ (or Nix Flake) which has all project dependencies listed. This only requires sharing /nix to the sandbox (and optionally adding nix to $PATH). Note that, although I use NixOS, Nix is supported on any Linux distro as well as on MacOS, so it should be OK to use, although I sometimes have some problems when using it to compile graphical apps (which can be worked around with tools such as nixGL⁸); there are other alternatives you can consider such as asdf / mise.
   • Unfortunately, Zed doesn't support activating per-project direnv in the editor yet, regardless of sandboxing (Use direnv environment #4977), so I have to re-launch Zed for each project I open using direnv. It's acceptable for me though.

With this, I've been able to do anything I'd need from Zed, which mostly includes having access to its editor features, having language servers work and also being able to use compilation tools from the terminal, regardless of whether they're installed in the host. Personally, I'm fine with and actually would rather prefer having language servers run in the sandbox as previously pointed out by @jtolio, so I'm fairly happy with my setup as is. Let me know if it'd be interesting for me to share more details (at somewhere other than this PR's comments, haha).

Footnotes

1. https://github.com/flathub/org.freedesktop.Sdk.Extension.rust-stable ↩

2. https://github.com/flathub/org.freedesktop.Sdk.Extension.dotnet8 ↩

3. https://github.com/flathub/org.freedesktop.Sdk.Extension.node20 ↩

4. https://github.com/flathub/org.freedesktop.Sdk.Extension.ziglang ↩

5. https://github.com/flathub/org.freedesktop.Sdk.Extension.openjdk21 ↩

6. https://direnv.net/ ↩

7. https://wiki.nixos.org/wiki/Development_environment_with_nix-shell ↩

8. https://github.com/nix-community/nixGL ↩

[3lpsy]

Thanks for the feedback ya'll! Seems like at the moment I can probably get 98% of what I need using the fully sandboxed Zed. I typically don't use the built-in terminal so that shouldn't be an issue. And so far I haven't noticed any tools I can't get from a flatpak extension or fiddling with paths and sharing specific binaries. Worst comes to worst, i can just make a custom flatpak extension but i don't see what I'd need to do that for yet as I mostly get by with just an lsp.