Zed as Flatpak! (Runs on Wayland natively)

[ShobuPrime]

Hello everyone! I'm happy to share my build for Zed as a Flatpak for Linux!

https://github.com/ShobuPrime/flathub/tree/dev.zed.Zed

It will be merged to Flathub soon given the proper approvals. Please let me know what you think!

[arslivinski]

It would be nice if this Flatpak was verified by being an official Zed release instead of a user package. Couldn't we add this to the official repository?

[ShobuPrime]

finished the flathub submission process

That's exactly why I created the topic here for feedback while I sort out the issues the Flathub maintainers notice according to their standards.

Prior to this, I've only released one other Flatpak for Enpass

Apparently one of the challenges of building and releasing this Flatpak (since it's compiled with cargo) is that it needs to be performed entirely offline from within the build steps and we rely on the flatpak-builder to aggregate and cache the dependencies. The current commit ATOW was built with the following build args:

      build-args:
        - --share=network
        - --filesystem=home

Which (while working if you clone and install manually) are not up to Flathub's standards.

A good example of a Rust application I personally use with Flatpak is Mission Center -- so now I'm learning how to make sure my next commit in the PR can build offline just like their manifest does.

When and if the Zed developers want to take over maintenance of the flatpak on flathub, they will easily be able to do so.

That is certainly the goal -- I don't plan to be the sole owner of the repo once it's submitted, but I also wanted to help offer a solution/option to use Zed other than only compiling from source.

[clseibold]

@ShobuPrime Right. I certainly appreciate the work you put into making the Flatpak. Flathub seems to be pretty restrictive on some things, and the sandbox is a bit more complicated to deal with while also adhering to Flathub's standards, so I think there's more work being done in the Flatpak v3 issue.

[someone13574]

Yeah, @ShobuPrime feel free to suggest/review anything in the v3 PR or to work on anything in the todo list. Its now at a point where there are zero sandbox related issue and will never have any sandbox issues because it simply exits the sandbox. It also has offline building.

[clseibold]

@ShobuPrime Btw, I think for offline stuff, @someone13574 uses cargo-flatpak-generator to generate a flatpak manifest that pulls in all of the cargo dependencies - I think that's how that works at least.

[someone13574]

Yes, the script generates a file that contains url's for the tar.gz of each dependency. This then allows flatpak to download the deps at the correct time instead of during the build process where flathub doesn't allow you to for reproducible builds and security reasons.

[someone13574]

This will have a ton of things broken due to spawning processes in the sandbox. This includes language servers and the terminal as the major ones.

[ShobuPrime]

I view this a simply an option, no different than how other code editors like VSCode exist -- and certainly don't expect it to be the primary installation method.

Flatpak has language specific SDKs which can be included in the manifest to have languages natively work within the Flatpak, such as Golang

I expect you can also use the host shell just like the VSCode Flatpak allows you to do. I've been using it just fine with no issues for Golang development.

On machines like the Steam Deck, where natively it doesn't allow you to edit the OS -- having an Zed packaged as a Flatpak is very beneficial -- even if it's just for text editing. In this example, not every Steam Deck owner is going to disable the RO-Filesystem.

[ShobuPrime]

If you give the Flatpak permissions to the D-Bus Session Bus

you can use your host shell as such:

I expect you can probably change your default Zed settings to always use the host shell if you're concerned about Sandbox

[someone13574]

A better way is to run the main app outside of the sandbox. See here: #12006