Fixes #359 - Implement Linux/Flatpak output for Briefcase#754
Conversation
|
Next steps:
|
|
@nickzoic I am really excited about this feature!
When we were developing Flatpak support in Gaphor, we didn't have much luck with getting reliable builds using flatpak-pip-generator. Instead we created a simple bash script that pip installed the needed packages and then put them in to a manifest in the right format. You might be able to take some inspiration from this and implement something similar in Python. |
Yeah, I don't know if it'll prove to be a good approach. I just hand-created the I think if we were to use the flatpak-pip-generator -like approach we'd have to mostly rewrite it but it's a good start on manifest generation & I went with that for now in an attempt to get something at least partially working. I'll have a look at your script too, thanks! Looks a lot simpler than what it's currently doing ... |
| # * flatpak-pip-generator is a python program which translates requirements.txt | ||
| # files into includable "python3-requirements.json" module *but* it isn't | ||
| # distributed on pypi, isn't a library and doesn't load pyproject.toml so I | ||
| # suspect we're better off doing this stuff here instead. |
There was a problem hiding this comment.
What Python version is being used here? One of the implied contracts of Briefcase packaging is that it uses the same Python version as the one doing the packaging. If I package this app on Ubuntu 22.04 (which uses Python 3.9 as a system Python IIRC), and then deploy on Fedora 28 which uses Python 3.6... what happens? What happens if my code uses the walrus operator? I'm not seeing anything in this flatpak definition that references a Python version.
There was a problem hiding this comment.
Yep, the python version comes from the flatpak "runtime", which is kind of a base image for the flatpak, itself also a flatpak.
The runtime is specified in the flatpak manifest https://github.com/beeware/briefcase/pull/754/files#diff-c3953738384a9db4f1f0e7c5000448f194a3906c3260fd510190dfb02a05d887R131-R136 ...
I'm just using an arbitrary one, but I'd considered using a --option to let the user choose one.
We could also pick the appropriate runtime to match the python version being used for packaging, plus it doesn't look too difficult to create custom runtimes based on the existing ones so we could make & publish our own ones per python version (though I haven't tried this yet)
There was a problem hiding this comment.
What's the line between "tool provided by the Runtime" and "binary dependency required to make the app run"?
In particular - how would the introduction of something like #628 interact with the choice of runtime?
Codecov Report
|
| "--socket=fallback-x11", | ||
| "--socket=wayland", | ||
| ], | ||
| } |
There was a problem hiding this comment.
Should this be part of a flatpak template, or is doing this in code a conscious decision?
There was a problem hiding this comment.
Could be templated instead (like linux/appimage is) but this was the quickest & simplest way to get a first implementation up and running as a proof of concept.
| self.logger.info() | ||
| self.logger.info(f"[{app.app_name}] Building Flatpak...") | ||
| try: | ||
| self.subprocess.run( |
There was a problem hiding this comment.
Does this call need to be dockerized - if only so that we can guarantee the existence of flatpak-builder et al?
There was a problem hiding this comment.
Yeah, maybe ... as you say, that way the dockerized build system is a known quantity. And have the same --no-docker flag as linux/appimage.
| # * flatpak-pip-generator is a python program which translates requirements.txt | ||
| # files into includable "python3-requirements.json" module *but* it isn't | ||
| # distributed on pypi, isn't a library and doesn't load pyproject.toml so I | ||
| # suspect we're better off doing this stuff here instead. |
There was a problem hiding this comment.
What's the line between "tool provided by the Runtime" and "binary dependency required to make the app run"?
In particular - how would the introduction of something like #628 interact with the choice of runtime?
Following this comment by Russell I thought I'd have a look into packaging as Flatpak. This is kind of a workaround for #718 maybe, but also having support for multiple Linux packaging solutions is a good thing in its own right.
Early days yet and this is very much a work in progress.
It builds the helloworld app and that's about it!
Much more work needs to be done to generate a good Flatpak manifest from the information in the pyproject.toml file but I thought it would be nice to have a PR for this work to live in.
PR Checklist: