Hover: app packaging

[pchampio]

Regrouping the issues related to app packaging:

• windows: Hover: windows #106
• linux: Packaging for linux #160
• Mac: Packaging for Mac #99 / MacOS Code Signing #179

Packaging can be done by the user, that why it's not our top priority.

We don't want to add too much dependencies in hover; what we would like to have is commands like hover package init-snapcraft, hover package init-innosetup. Those commands will create templates files that can be customized by the user; once the user is happy with the configuration, he can run manually the actual program that does the packaging.

Packaging Status:

• Linux - Add Linux packaging support hover#15, supports: Snapcraft & deb
  --------- Add support for linux-appimage hover#39, supports: linux-appimage.
• Windows - Add support for windows-msi hover#40, supports: windows-msi
• Mac - Add support for darwin-bundle and darwin-pkg hover#42, supports: darwin-bundle and darwin-pkg

Packaging requires Docker, using docker, you can package from any platform TO any platform. Many thanks to @jld3103 for his work!

[joeblew99]

Maybe a different repo then within the org ?

I would really like to see the polish of proper packaging.
I started to do some but got side tracked.

I was also working on auto updating functionality. Again not finished.

[pchampio]

@joeblew99 no it should not be in another repo of the organization.
It should be another hover command.

[provokateurin]

I think it would be better to not have to initialize the packaging, because the configuration files for will change when the pubspec.yaml changes and have to be regenerated. I would prefer something like this:

hover package snapcraft
hover package innosetup

[GeertJohan]

There's a lot of nice stuff in go-flutter-desktop/hover#15. Thanks @jld3103 for getting started on this story and working out a viable solution.

I've been discussing with @Drakirus about how to fit packaging into the hover cli. A number of idea's came to mind, and after some brainstorming we've come to realize some changes are required to improve how the packaging features can be used by developers.

In the examples here I will pretend that go-flutter-desktop/hover#12 has already been merged, which means that the desktop directory has been renamed to go. So there is go/cmd and go/build and go/go.mod etc.

Packaging and distribution works differently on desktops than it does on mobile. For starters, packaging is optional. The current build outputs can be zipped and distributed. There is no complex structures or file formats needed like there is for mobile.
For desktops, there are tens of different packaging methods, which you may all want to use at the same time to cover a broad range of users. Whereas for iOS there is just one way to package your app. And for Android there are two, of which you'll probably only use one at a time (apk vs aab). ((ofcourse aab contains apk's, but lets focus on the final outputted file for distribution)).

We propose a structure where configuration for packaging tools is separated from the packaging process and the actual packaged output.

Packaging methods
Packaging methods are each implemented specifically for one OS. Their names consist of the OS, and the packaging kind joined by a dash; $os-$packagingName. e.g.: linux-snap, darwin-dmg, windows-msi.

Packaging configuration

Packaging configuration is stored in a folder which should be included in git (we don't exclude them in our boilerplate .gitignore files). The directory path follows the structure go/packaging/$packagingMethod. e.g.: go/packaging/linux-snap.
Packaging configuration is generated once, by running a specific hover command for each packaging format that the user needs; hover init-packaging <packaging method>.
For example: hover init-packaging linux-snap creates a folder go/packaging/linux-snap and the file go/packaging/linux-snap/snapcraft.yaml inside it. This file is never overwritten by hover. Users may remove go/packaging/linux-snap and run hover init-packaging linux-snap again to regenerate the file. The file may be modified manually, just like users can modify all configuration in the android or ios directories inside a flutter project.

Packaging and packaged output

Packaged output files are stored in go/build/outputs/$packagingSolution.

Breaking change to hover CLI

A breaking change to the hover CLI will be introduced. Currently, flutter build just prints help message, you'll have to select a build target (apk, ios, etc.). However, hover build defaults to the current OS platform and no target platform can be specified. This will be changed; hover build will print help and a second subcommand is needed to actually start a build. The second subcommand can be a target os (linux), or a packaging method (linux-snap). Some examples:

• hover build darwin builds raw (non-packaged) binary file for use on darwin, outputted in go/build/outputs/darwin. This is exactly the same as running hover build on a Mac today. The output files are the same, it just becomes mandatory to explicitely state the target platform.
• hover build darwin-dmg builds for darwin, then packages the dmg and stores it in go/build/outputs/darwin-dmg/$projectName.dmg
• hover build linux-snap builds for linux, then packages the snap and stores it in go/build/outputs/linux-snap/$projectName.snap

This breaking change will also be beneficial to future cross-compiling efforts.

[provokateurin]

@GeertJohan On mobile the version of the app changes with the version in the pubspec. The way you mentioned only generates the files once and the user would have to update the version manually.
Otherwise I agree with you, but at least the version should be generated every time.

[joeblew99]

@GeertJohan Your approach outlined above looks really good.
Like how extensible it is. I can see go-flutter being used for many diverse projects this way.

Going to try out the branch and see if i can help.

[GeertJohan]

@jld3103 you mean the version number?

[provokateurin]

@GeertJohan yes

[GeertJohan]

@jld3103 I agree, but currently we dont have a version number compiled into the binary anyway. It's still on my wishlist though, with support for override via the --build-number and --build-name flags as well.

[provokateurin]

New packaging formats:
linux-appimage: go-flutter-desktop/hover#39
windows-msi: go-flutter-desktop/hover#40
darwin-bundle and darwin-pkg: go-flutter-desktop/hover#42

[pchampio]

The feature got released into hover v0.33.0
Thanks to @jld3103, I'll close this issue.