beeware
Debian 10 (Buster) version of Flatpak silently fails to install app with spaces in name
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 0d7c3594
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 https://github.com/flatpak/flatpak/issues/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
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.
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.
