Push Sublime 4 via Flatpak (support musl)

[dm17]

Problem description

This seems relatively easy for the sublime devs to push through, especially for the payoff (supporting the latest sublime for all those non-glibc distros):
flathub/flathub#2855

Preferred solution

flatpak supports glibc apps on non-glibc systems

Alternatives

Build sublime 4 for musl (not necessary, the above is practically done)

Additional Information

No response

[BenjaminSchaaf]

Flatpaks break a lot of functionality for ST. Build systems, cli, sublime merge integration, etc. As such we won't be officially supporting flatpak or snap builds.

[dm17]

But com.sublimetext.three has been serving me well for a long time - so is there something special about st4 that doesn't jive with flatpak? Or same problems in st3? I haven't experienced issues yet.

[BenjaminSchaaf]

The issues with flatpak are inherent to how flatpak works. The basics certainly work so you may simply have not used the parts of ST that don't.

[x80486]

There are plenty of ways to tackle these problems.

I don't see any of those two formats (Flatpak or snaps) going anywhere, so you are going against the mainstream...and at some point Sublime * will be the one left behind.

[BenjaminSchaaf]

@x80486 Please do explain how these problems can be tackled. All the research I've done has shown it's impossible and entirely against the design of both Flatpack and snap; so if you can shed some light on how to circumvent the sandbox they provide in order to properly integrate with development environments that would be most welcome.

[x80486]

I think the best course for this is to enumerate the current issues on your end — and I can try to find the solutions. I just have some experience in some areas, and I'm not shy at all looking for help within the observable Universe.

I can tell you beforehand that, for some of the issues, the software would have to change considerably because of the sandbox — some end users underestimate what that brings up to the table because some applications are not ready, and probably won't be if the owners don't change some things, but these formats look very promising in many aspects, IMO.

On a side note, it would be a little bit tricky since the actual software is not packaged in such fashion. I know there was an effort to submit Sublime Text 4.x, but there was some serious nonsense around a particular way to display some warning at startup.

[BenjaminSchaaf]

I'll describe the some major ones:

ST needs to provide a CLI - the subl executable (https://www.sublimetext.com/docs/command_line.html). It needs to support stdin/stdout, running multiple instances with different profiles/users, waiting on the main process - ie. it needs full IPC. It also needs to be installed along with the app since they need to be updated together.

ST needs to be able to run processes outside the sandbox, where the user's development environment resides. If they install any kind of tooling, build systems need to be able to run them. Plenty of third party plugins also rely on the user installing some tooling themselves that is then accessible to ST. (This also means access to the PATH outside the sandbox)

ST needs to be able to run as root. Occasionally users want to edit system configs or other files that require root. ST can either be run fully as root with a separate profile, or prompt when saving a file that requires root.

[dm17]

I'm assuming everyone who has been using Sublime via flatpak now sees this:

Info: runtime org.freedesktop.Sdk branch 21.08 is end-of-life, with reason:
   org.freedesktop.Platform 21.08 is no longer receiving fixes and security updates. Please update to a supported runtime version.
Info: applications using this runtime:
   com.sublimetext.three