Developing applications using Flatpak-packaged editors/IDEs


#1

Hi!

I’m really excited about Fedora Silverblue and how I could convert my “classical” Fedora workstation to it.

Currently, I’m exploring using Flatpak versions of certain applications instead of their classical RPM counter-parts. And I must say it works well for many applications.

One area where I’m having trouble figuring out how things should work in the new Silverblue landscape is with Flatpak-packaged editor/IDEs in relation to application’s software stacks.

For example, a developer is working on a Python application and wants to use Visual Studio Code (OSS version) from Flathub as his development environment.

The org.freedesktop.Sdk/x86_64/1.6 runtime on which the current app/com.visualstudio.code.oss/x86_64/stable is based on (at the time of writing) provides Python 3.5.2 and Python 2.7.12.
This is serious limitation since two new Python versions were released in the mean time, 3.6 and 3.7, and are available in Fedora “classic” Workstation.
Furthermore, one can’t simply configure VS Code to use the host-installed Python executable with a corresponding Python virtual environment since such attempts fail with:

/home/tadej/.local/share/virtualenvs/temp/bin/python: error while loading shared libraries: libpython3.6m.so.1.0: cannot open shared object file: No such file or directory

More generally, when someone develops an application he usually wants to have complete control of the whole software stack, from the version of the language it uses to all the dependent libraries and their versions.

How does Fedora Silverblue plan to tackle this use case?


OKD on silverblue by default?
#2

Thanks for posting this! I helped create Silverblue, and I’d probably say this problem is my biggest pain point too. It’s where the flatpak vs podman/docker vs host divisions comes strongly to the fore.

In some sense it’s a generic flatpak issue - I’m not sure if there is one upstream or not.

But it’s also a Silverblue issue in that on a classic system one could more easily take the “out” of using flatpak just for simple/fixed apps, and install IDEs+tooling on the host. You can of course do that on Silverblue too…but it’s fighting the system a bit.

The other alternative is to install the IDE inside a pet podman container and give it access to X/Wayland etc.; would require reinventing some of the flatpak⇔desktop integration.

Yet another path would be for flatpak to grow some mechanism to “derive” from an app (much like OCI layering) and add e.g. other Python versions or Rust/whatever to it. Flatpak today does have Extensions but I am not sure about using them for this case.
Probably the best thing here would be for an IDE maintainer to comment.


#3

I do a lot of golang. I found this by another golang writer trying flatpak: https://dev.to/satimewallin/go--mess-with-flatpakvscode-ja6

Seems to work pretty well so far. Though not ideal having to keep everything in home folder, but it works.


#4

@walters, thanks for sharing your thoughts. Since this is quite a new area, one could think that things are just not properly documented.

I did a bit of searching in https://github.com/flatpak/flatpak/issues and the only related thing I’ve found is https://github.com/flatpak/flatpak/issues/1412.

Therein, Alexander Larsson mentions how Pitivi uses Flatpak as a development environment, but that is a bit different use-case since there you have an upstream project providing a 700+ lines Python script implementing the Flatpak-based development environement along with a Bash script providing aliases and shortcuts for this environment.

I think you’ve nailed it here. For example, I’ve just stopped using
VSCode’s Flatpak and switched back to using the host-installed RPM version.

Yes, I could probably do the same on Silverblue via rpm-ostree layering but as you’ve said, it’s fighting the system a bit.

Yes, one could probably do that, but it feels pretty hackish and very manual from the outset.

This approach has the most potential, in my opinion. But as I’m reading the current Extensions description, Flatpak Extentions appear to be something static, i.e. a Flatpak extension is similar to an RPM subpackage, it is available to extend the file-system of a Flatpak to provide translations or debug information that is not part of the main Flatpak.

On the other hand, a developer would need a user-defined read-write OCI layer on top of a Flatpak file-system where he could install his application’s binaries and libraries. E.g. install the desired version of Python and pip-install the desired versions of application’s libraries.

Agreed. Do you know any we could @ mention to look at this topic?


#5

@geekgonecrazy, thank’s for the pointer.

I’m afraid this solution is very Go-specific since Go applications are usually distributed as single statically linked binaries and you can get away by putting them in your home folder and bind-mounting it in the Flatpak sandbox.
But this won’t work with other languages and applications that aren’t statically linked. Not to mention that I don’t want to manually fetch these binaries and store them in my home folder.


#6

So, this is a commonly asked question, and there is no full answer to it, but there are several options that, by themselves or as a combination, moves toward solving this.

The first option is the one chosen by gnome-builder. gnome-builder tightly integrates with flatpak and doesn’t actually build things in the context of the gnome-builder sandbox and its runtime, instead if recursively creates other sandboxes for builds. This means that you get to pick any runtime for your builds which may be completely different than the one that runs gnome-builder itself. This is quite powerful, but requires a lot of intimate support for this model in the IDE.

The second option is to extend the app/runtime via flatpak extensions. Flatpak already supports this in the Sdk, with the org.freedesktop.Sdk.Extension extension. Flathub currently hosts sdk extensions for mono, openjdk 8+9, rust and gcc 7 + 8. These are compilers that are not supported natively by the Sdk, but you can still use them.

Effectively what this mean is that if you install say org.freedesktop.Sdk.Extension.rust-stable and run something against the freedesktop sdk (or derivates) a directory will appear in /usr/lib/sdk/rust-stable/ that has the compiler and tools for rust. All you have to do is add it to PATH and then you can build some rust app.

It has been proposed to add a similar extension point for IDE-like tools so that you can easily add the tools you need to them. This would be done in a way that allows these extensions to be shared between different IDEs.

The third way is to use the dbus service that comes with flatpak to break out of the sandbox. This needs the app to have explicit permissions for this, but once you have this you can use the flatpak-spawn --host command in the sandbox to start commands on the host (or call the dbus directly which is what gnome-builder does when it spawns you a terminal on the host inside its window).

I think different problems call for different solution, but a combination of the above is pretty compelling.


#7

The first option is the one chosen by gnome-builder. gnome-builder tightly integrates with flatpak and doesn’t actually build things in the context of the gnome-builder sandbox and its runtime, instead if recursively creates other sandboxes for builds. This means that you get to pick any runtime for your builds which may be completely different than the one that runs gnome-builder itself. This is quite powerful, but requires a lot of intimate support for this model in the IDE.

There’s a variant of this - which is for the IDE to do builds in a container. If the end thing you are creating is a graphical application, then doing the builds as Flatpak builds makes a lot of sense. If the end thing you are creating a server app, then a container build is going to work better - and also allows using prepackaged Fedora dependencies. I don’t know of any examples of setting up a Flaptak’ed IDE to target container builds, but many IDE’s will have some sort of container support that can potentially be adapted for this purpose.


#8

Right, that’s the case for me - I am using Silverblue primarily to develop server-side apps for Kubernetes (and base operating system components), not desktop apps. So the flatpak IDE story basically crosses all 3 systems (flatpak, dev/pet containers with podman, and local oc cluster up testing).


#9

I’m a newbie at this but I had briefly looked at what Theia IDE is doing and I like some of their ideas https://www.theia-ide.org/doc/Composing_Applications.html for composabilty

This tooling issue is real and I guess a lot of us need to readjust to this container mindset to be productive.