Debian 10 (Buster) version of Flatpak silently fails to install app with spaces in name

[mhsmith]

OS packages:

ii  flatpak                            1.2.5-0+deb10u4              amd64        Application deployment framework for desktop apps
ii  flatpak-builder                    1.0.5-1                      amd64        Flatpak application building helper
ii  libostree-1-1:amd64                2019.1-1                     amd64        content-addressed filesystem for operating system binaries (library)

Briefcase commit 0d7c359

Running briefcase run linux flatpak on the default Hello World app, I get this output:

Committing stage finish to cache
Exporting com.example.helloworld to repo
Commit: 2de9c80b522b4385bac78d69632c12aa6a8a33399553a3e546665c2b1160b49c
Metadata Total: 889
Metadata Written: 431
Content Total: 8542
Content Written: 6616
Content Bytes Written: 147762534 (147.8 MB)
Exporting com.example.helloworld.Debug to repo
Commit: 9c8c91b06ba5bbd627337bd0ec331ed41896a46d64402ec00075b2ef0d98e744
Metadata Total: 21
Metadata Written: 10
Content Total: 77
Content Written: 77
Content Bytes Written: 8848023 (8.8 MB)
Installing app/com.example.helloworld/x86_64/0.0.1
Pruning cache
Building... done

[helloworld] Built linux/flatpak/Hello World/com.example.helloworld

[helloworld] Starting app...
error: app/com.example.helloworld/x86_64/master not installed

Unable to start app helloworld.

Log saved to /home/smith/git/beeware/helloworld/briefcase.2022_07_28-20_53_54.run.log

briefcase.2022_07_28-20_53_54.run.log

The build and install appears to have succeeded, but the app isn't listed by flatpak list:

(bw-dev) smith@chaquo:~/git/beeware/helloworld/linux-stub/flatpak$ flatpak list --app
(bw-dev) smith@chaquo:~/git/beeware/helloworld/linux-stub/flatpak$

Running the flatpak-builder command manually also appears to succeed, but the app still isn't listed.

This appears to be related to flatpak/flatpak#4378, except that instead of giving an error, the install just failed silently. If I rename the directory to remove the space, and rerun, then it works:

(bw-dev) smith@chaquo:~/git/beeware/helloworld/linux-stub/flatpak$ mv Hello\ World/ Hello
(bw-dev) smith@chaquo:~/git/beeware/helloworld/linux-stub/flatpak$ cd Hello
(bw-dev) smith@chaquo:~/git/beeware/helloworld/linux-stub/flatpak/Hello$ flatpak-builder --force-clean --repo repo --install --user build manifest.yml
...
Content Bytes Written: 0 (0 bytes)
Installing app/com.example.helloworld/x86_64/0.0.1
Pruning cache
(bw-dev) smith@chaquo:~/git/beeware/helloworld/linux-stub/flatpak/Hello$ flatpak list --app
Description    Application               Version    Branch   Arch     Origin              Installation
helloworld     com.example.helloworld               0.0.1    x86_64   helloworld-origin   user

[mhsmith]

This isn't the first time we've had problems caused by spaces in paths, and I'm sure it won't be the last. Spaces also cause various usability issues, including:

• Can't select the whole path in the terminal with a simple double-click.
• Pasting the path into a command line requires manual insertion of quotes or backslashes.

So I think we should consider naming directories with the spaceless app name, rather than the formal name as we do now. Of course, we'd still need to recognize the formal name in existing projects.

[freakboy3742]

Ugh. /me waves fist at clouds.

FWIW, my test app for flatpak has been "Hello World" on an Ubuntu 22.04 box with flatpak-builder 1.2.2 and flatpak 1.12.7, and the space isn't a problem. However, I just tested on an Ubuntu 18.04 box with with flatpak-builder 1.0.14 and flatpak 1.12.7, and while the build completes, the run doesn't.

Regardless, I think you're probably right - there's enough headaches in dealing with spaces that it's worth moving to using the app name as the bundle path.

The annoying thing is that the formal name needs to be fixed in both briefcase and the template, which means the path to making this change is going to be complex.

The (small) silver lining is that we've got a general policy that the contents of the build products are transient, and shouldn't be relied upon as permanent artefacts (i.e., they shouldn't be committed to version control); so we don't need to worry about migrating projects - we just need to work out how we're going to support "version of briefcase that is expecting to find code in platform/formal name when the template produces platform/app_name.

A related thought: in order to address #424, I've been contemplating whether we should move to a directory structure more consistent with Python's packaging folders (i.e., a build and dist folder). Although this is a much bigger structural change, it's related; and if we're going to mess with paths, it would be good to do it once, rather than needing to make multiple passes.

[rmartin16]

As another datapoint, the Flatpak build fails on Ubuntu 20.04.

Flatpak 1.6.5
flatpak-builder 1.0.10

briefcase.2023_02_13-15_44_24.build.log

[freakboy3742]

@rmartin16 This is an issue with the version of flatpack-builder that ships with Ubuntu 20.04. We discovered this when we set up the verification builds in CI; until recently, the CI config had a comment. that specifically referenced this problem (at least partially because ubuntu-latest on Actions wasn't 22.04 until late last year).