Abderrahim Kitouni commented: > Surely that should be the goal. We don't have any reason to continue > non-flatpak builds, right? Yeah, of course. BTW, when will I be able to create web apps from flatpak epiphany? :stuck\_out\_tongue\_winking\_eye: > I think we should aim for making it as painless as possible for the app > maintainers, even if that means the RT would have to maintain a separate > build definition (gnome-build-meta) and let the apps continue using their > flatpak manifests as their source of truth. I agree with that. I see it more like: 1. let apps keep use their flatpak manifest for now. 1. work on the buildstream flatpak plugin so it implements the most commonly used flatpak-builder features 1. start syncing the manifests to gnome-build-meta (so while the flatpak manifests are the source of truth, gnome-build-meta has the same thing) 1. when gnome-builder gains support for buildstream (it's in the roadmap for 3.34, so hopefully soon) we can start phasing out the flatpak manifests. > One issue though, is what would happen to the development/test experience > with buildstream (nobody uses it yet, but we shouldn't make the workflow > worse). Would this mean that for every change we would have to checkout a > flatpak bundle and run that? And if so what would be the required changes in > the bst plugin to make this as easier, like `flatpak-builder --install` or > such. The development/test experience with buildstream goes like: ```bash bst workspace open some/element.bst ~/some/dir cd ~/some/dir # hack cd ~/path/to/gnome-build-meta bst build some/element.bst bst shell some/element.bst # test ``` (with bst master, you can run `bst build` and `bst shell` directly from the workspace without specifying the element). If testing in flatpak is desirable, it isn't hard to write a script to do the equivalent of `flatpak-builder --install`. It can be made easier by making the flatpak plugin produce a repo directly, so it is just a matter of running `bst checkout` + `flatpak install`. -- Reply to this email directly or view it on GitLab: https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/133#note_514031 You're receiving this email because of your account on gitlab.gnome.org.
_______________________________________________ gnome-infrastructure mailing list gnome-infrastructure@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-infrastructure
