Flutter Snap Structure Options

kris · September 20, 2022, 1:40pm

Hi all,

I was wondering if anyone knew the most future-proof way to build a flutter snap, as we are torn between the more traditional gnome-3-38-extension or gnome-extension method or the newer graphics-core20/mesa-core20 method as seen in this post.

Both of these options allow us to use the core20 or core22 base for the snap which seems like the right move to make it future proof.

The reason we want it to be future proof is that the snap and ubuntu core image that contains it is going to be deployed on some iot hardware in locations with potentially bad network connectivity and which a full large remodel would potentially be difficult or ideally avoided as much as possible.

A little bit of background.

We are working on a snap which was using the flutter-extension to build the snap and allow it to display the UI via mir-kiosk.

We noticed as we were building the flutter binary outside the snap build process we didnt need the additional flutter tooling that extension provided so moved to the gnome-3-28-extension. However this was still based on core18.

We have tried both methods extension vs the graphics-core20 content snap and both seem to be working fine. We think the extension method makes the snapcraft.yaml look a little more readable by hiding some of the complexity, but the graphics-core20 method seems to suggest we could update the mesa-core20 snap and flutter snap independently.

It would be great to hear your thoughts on which of these is the future direction for UI based snaps for ubuntu core.

kenvandine · September 22, 2022, 1:49am

We have plans to update the flutter extension in snapcraft, but for the most future proof means you could do something like this:

github.com

ubuntu-flutter-community/software/blob/main/snap/snapcraft.yaml#L20


  Snap Store can also be used to switch channels, manage snap permissions, install traditional packages (deb/rpm), check for and install updates.
confinement: strict
base: core22
grade: stable
license: GPL-3.0+
assumes:
  - snapd2.41 # for appstream-metada and packagekit-control
parts:
  flutter-git:
    source: https://github.com/flutter/flutter.git
    source-branch: stable
    plugin: nil
    override-build: |
      set -eux
      mkdir -p $CRAFT_PART_INSTALL/usr/bin
      mkdir -p $CRAFT_PART_INSTALL/usr/libexec
      cp -r $CRAFT_PART_SRC $CRAFT_PART_INSTALL/usr/libexec/flutter
      ln -sf $CRAFT_PART_INSTALL/usr/libexec/flutter/bin/flutter $CRAFT_PART_INSTALL/usr/bin/flutter
      export PATH="$CRAFT_PART_INSTALL/usr/bin:$PATH"

Look at the flutter-git part in that yaml, it grabs flutter from git, switches to the desired channel and does the build. This also uses the latest “gnome” extension, which will be future proof. It’s not quite as convenient as the flutter extension is, but will work as long as the flutter tools don’t change how the build works.

We’ve been building a number of projects this way as we’ve moved to core22 and it’s working very well.