Installing Flutter SDK via Snap or Brew
Dec 30, 2021
Ubuntu is the most popular desktop Linux distribution, especially if we count all of its derivative Linux distributions. The relationship between Ubuntu and Flutter is getting tight: the Ubuntu operating system installer got implemented in Flutter lately. Another new change of the latest Ubuntu version is that the built-in software store is based on SnapCraft and users would pick and install snaps rather than Debian packages via apt.
This use of Snap circles back to Flutter: currently the primary advised installation method of the Flutter SDK on Linux is via snap. Snap has a package dependency on systemd, and since I use systemd-less Debian flavor called Devuan I had to go the secondary way: install Flutter SDK manually. Manual installation is simple. One essential portion of the installation is cloning the GitHub repository, and an upgrade for example would pull the latest changes, then kick off some compilation and other companion tasks based on the new source.
Systemd penetrated almost all the Linux eco-system: on one side rooting from Debian and its biggest derivative Ubuntu, and a whole bunch of Ubuntu derivatives and on the other side throughout the other largest derivative tree which is based on Fedora / RedHat. That latest distribution family tree is not a surprise because systemd originates from Lennart Poettering, a software engineer at RedHat, long time Linux contributor. Even if someone is not using Ubuntu, snap is available as a native package and with that, we create an extra layer of package distribution eco-system above the operating system’s native package management. A big advantage of snaps is that you won’t hit any dependency roadblocks because snaps are self-containing. You can also easily switch between various versions of software or SDKs. Although the manual installation of the Flutter is easy, it is certainly easier to just install it with one single snap command.
At the same time, Flutter has very low friction and awesome CLI. Developers can extremely easily get info on the healthiness of their Flutter installation (flutter doctor), upgrade to the latest version (flutter upgrade), or switch between stable / beta / nightly distribution channels. The question arises: once someone installed Flutter via snap or brew, how should it be kept updated? On one hand, various IDEs (Integrated Developer Environments) like Android Studio or Visual Studio Code will check time-to-time and warn if a newer Flutter version is available. These tools most probably do that the Flutter CLI way and would promote a flutter upgrade. However, Snap as a package distribution eco-system would also - supposedly - have new versions of the SDK and would warn about those through other operating system channels respectively.
This can create dissonance, interference, maybe even confusion since the Flutter SDK GitHub repository would always certainly provide the most up-to-date version, while Snap and Brew packages could follow the changes after some lag, or sometimes very significant lag. This latter thing happened not so long ago: in an unrelated issue in October I realized that a fellow Linux user installed Flutter from snap and SnapCraft at that time had an embarrassingly old package (built in August) offering an even more embarrassingly old SDK version (2.2.1 is a version from May). The Linux user thought that after the snap install he would have the latest version. After raising two issues in the Flutter GitHub repository (see Flutter Snap package is extremely outdated #93495 and Snap builds are not triggered for several months now #93497) it turned out that the CI/CD (Continuous Integration / Continuous Delivery) pipeline had a mechanism to build a snap package but that got mute after some storage bucket changes. That issue got solved and there was a new Snap build on November 15th as a result.
Then I realized that even if the snap packages would be semi up-to-date that could still pose a dual signal, and it would be good to have a policy on how someone is supposed to keep the Flutter SDK installation up-to-date. Once the package starts to lag behind and the developer upgrades through CLI should the developer stick with the CLI from then on? In any case, snap and brew should have the most up-to-date versions possible. The package manager could still interfere and may advise overriding a fresher local state with an older version? These are not infrastructure issues but rather documentation issues so I opened tickets about the Linux installation (PAGE ISSUE: Linux install #6460) and declaring the policy on upgrade when installing from a side-channel (PAGE ISSUE: Declare clear upgrade policy when installing the SDK via snap on Linux #6499).
Interestingly the same question would arise in Mac OSX environments. The official Flutter documentation only outlines the manual installation on OSX however I can guarantee that every developer already has the homebrew alternative package management system on their machine. Therefore many developers simply install Flutter via brew because they see that it is available there and it’d be a one-command install just like in the case of snap. Brew is very up-to-date and it already offers the 2.8.1 stable version which came out almost two weeks ago. My fellow developer was not able to simply upgrade to that package though, so some force is needed by brew upgrade –greedy. Also see this or this.
That is not the most ideal picture because the developer would need to apply some extra magic, but at least brew offers the latest version. And once again: brew is not an official installation method. SnapCraft on the other hand is a primary installation method and it still only offers the mentioned November 15th build, while 2.8.0 already got released on 12/8/2021 and 2.8.1 came out on 12/16/2021 if we only look at the stable channel. So I opened a new regression ticket (Snap package version is lagging behind #95989), maybe there is some regression error in the CI/CD pipeline?
What is your opinion about alternative package manager-based installations and how to keep the SDK upgraded? Did you install the SDK manually or via snap or brew?