linux support

[glyph]

How should Linux support work?

One way would be to have some sort of build system that always carefully only links against libc 5, does everything statically, etc, and builds everything into a big binary.

Another would be to instead have multiple backends for .rpm, .deb, etc. I imagine that this would be different from bdist_rpm, bdist_deb et. al. by doing some automatic determination of what the package dependencies ought to be by looking for shared library dependencies. Despite the fact that this would not be nearly as self-contained, it might be more practically useful to begin with.

[freakboy3742]

Good questions all. It's been a while since I've done desktop Linux, so I'm not in the best position to provide answers, but my initial impression is:

• The focus is on standalone desktop applications.
• RPM/DEB packaging will probably be involved, but it's different to bdist_rpm and bdist_deb
• Virtualenvs will also probably be involved. App dependencies shouldn't be installed in system path, so the install process will be creating and installing a virtualenv that will be used at runtime.
• On installation, app icons should be installed in wherever the platform puts applications in the desktop menu structure.

[hawkowl]

So, from my experience, I would say that targeting .deb and .rpm is both doable and probably better than one big binary that you put somewhere -- fpm is good at handling this. Still, it would probably have to be Ubuntu/Fedora/etc specific.

What I think you would want to do is:

• Get a Python 3.5, extract it into /opt/<appname>
• pip install the dependencies into it, setting the environment CFLAGS to compile only for i386 or base x64
• pip install the app into it
• Write out a desktop file to /usr/share/applications, with a pointer to the icon + name + etc
• Uses fpm to bundle it up.

I think that statically bundling anything here is a bad idea; instead you should be able to express what your dependencies are in the briefcase config, and use system ones. Compiling this on an older Ubuntu (e.g. 14.04) would mean that it'd work on 16.04 and conservative CFLAGS would mean it'd operate on all processors.

now, gobject..... I think if you compile it on 14.04, it SHOULD work... it seems to be binary compatible with different versions of GTK; but I've not a clue how to compile it. From https://wiki.gnome.org/Projects/PyGObject it looks like you can specify a Python to build against. https://github.com/GNOME/pygobject/tree/pygobject-3-18 SHOULD compile on 14.04 and work on newer ones...

[burhan]

I think fpm will automatically prefer system dependencies; as per the docs.

[Hwesta]

Given how different deb, rpm and other Linux distros (eg Arch) are, does it make sense to have separate commands for the different targets? I was thinking linux-deb linux-rpm and linux-arch. I run Arch, so I'm interested in trying to get briefcase to generate an Arch PKGBUILD or .tar.xz package.

[brakedust]

I haven't looked into building any yet, but would Snap or Flatpak packages make sense?

[freakboy3742]

@brakedust I'm not 100% up with the state of app distribution on Linux, but from what I'm seeing, Snap/Flatpak would make sense, yes.

Completely outside from the implementation - the end goal is that a user can:

• be given a single bundle (or a URL to a bundle, or whatever is platform appropriate),
• they can install that bundle using their normal system tools
• the app will appear in system menus, be registered as an "installed" package, etc.

[andrewleech]

While I haven't used it yet myself, I think Flatpack would be a great next step. It would be a big improvement over the "here's a folder you can copy onto your linux pc" briefcase currently has and should provide most of the distro-specific things for us (system menu integration, installation dir etc)

It has a great range of distros currently supported: http://flatpak.org/getting.html

Regardless of packaging format, long term I think it'd be best to not depend on system python.

• These can have incompatibilities with binary packages our app might include
• Can cause package conflicts if you don't ensure system packages are not used
• It can be difficult to install the required version on distro x

For this we'll need standalone / portable copy of python to include with the app package.

I'd suggest either cherry-picking them out of the official manylinux docker images: https://github.com/pypa/manylinux
Or forking that repo with it's automated builder but output the binaries rather than producing the docker image.
This has the advantage of full compatibility with binary linux wheels that are starting to make their way onto pypi thanks to the manylinux project.
This project doesn't currently provide support for arm platforms however, this has been discussed with some workarounds: pypa/manylinux#84

Another option is the various miniconda distributions: https://repo.continuum.io/miniconda/
These have the advantage of proven compatibility on multiple platforms and are ready to go, however it means being somewhat tied to that project for support and updates.

[freakboy3742]

@andrewleech Completely agreed that Flatpak looks attractive; and I'm agreed with the problems you point out regarding using system python - except for one hiccup: GTK+ bindings can't be pip installed, and require the system Python. If there's another way to package GTK+ for a Flatpak, I'm all ears.

[andrewleech]

Looks like it should be a non-issue, one of the main "runtimes" of flatpak is gnome framework which includes all the GTK+ libraries: http://flatpak.org/runtimes.html#gnome

Basically the idea of flatpak is similar to docker in that it's intended that the distributable package includes all the dependencies with it, minimising compatibility issues at the cost of increasing it's disk/download size.

[lazka]

GTK+ bindings can't be pip installed, and require the system Python. If there's another way to package GTK+ for a Flatpak, I'm all ears.

pygobject can be installed with pip now btw https://pypi.org/project/PyGObject. But as stated above, for flatpak the gnome runtime should include everything needed.

[freakboy3742]

@lazka Thanks; we merged beeware/toga#442 a couple of days ago, so Toga now uses pygobject to provide the GTK dependency.

[loganasherjones]

Does anyone (@freakboy3742) have a strong feeling between flatpak and snapcraft?

Near as I can tell, the pros/cons list shapes down to something like:

Snapcraft

Pros	Cons
Much better documentation than flatpak	Supports fewer linux distributions
Better support for python proper (i.e. less code in this repo)	To install/run the build tool on not Ubuntu 16.04, will need to install docker or snapcraft
The manifest file is easier (in my opinion) to reason about

Flatpak

Pros	Cons
More Linux Distros supported	Documentation is less then stellar
The builder can be installed natively on more systems than snapcraft	Less "built-in" support for python

[freakboy3742]

@loganasherjones AFAICT, we should be able to support both (along with raw RPM/DEB packaging as well, for that matter). From my perspective, it's just a matter of having someone with expertise in one of those packaging toolchains building out the application template and describing the compilation/packaging process.

[freakboy3742]

I've just landed the 0.3 branch, which adds AppImage support for Linux. This development version also has placeholders for adding Snap and Flatpak.

Closing this on the basis that Linux is now officially supported in a meaningful way; I'll (eventually) open specific tickets for Snap and Flatpak support.