Snap installation not compatible with modules

[jmooring]

There have been two (probably three) reports:

• https://discourse.gohugo.io/t/hugo-server-is-not-starting-locally/28061
• https://discourse.gohugo.io/t/snap-binary-errors-with-hugo-modules/20700
• https://discourse.gohugo.io/t/alpinejs-with-hugo/22921

This limitation should be documented here:
https://gohugo.io/getting-started/installing/#linux

[jmooring]

From time to time I question the value of maintaining a snap installer. Problems:

1. Go modules (this issue)
2. PostCSS is broken (Postcss error with snap install of Hugo 0.70 hugo#7278)
3. Limited to $HOME access (discussion here: Issue with the snap installed version hugo#3143)

Snaps are great for accessory applications such as calculators, music players, and the like, but I feel that the snap security model hinders rather than helps when running some development apps.

[bep]

Yea, Snap was sold to me as something "maintainance free", but I @anthonyfok (and I and others) have spent countless hours making it ... work.

[jmooring]

Perhaps those hours would be better spent on other things. I have no idea what percentage of total installs are snaps.

[bep]

What do you think @anthonyfok ?

[anthonyfok]

Hi all,
Thanks for the @ mention, bep, as indeed I haven't been following the issues and was not aware of the new problems end users are experiencing with the Hugo snap build.

Snaps are great for accessory applications such as calculators, music players, and the like, but I feel that the snap security model hinders rather than helps when running some development apps.

That's a good point, and actually, there are security models to choose from. From https://snapcraft.io/docs/choosing-a-security-model:

Confinement can be one of the following:

devmode: enables system access and logging only while creating a snap
strict: denies all system access other than through a snap’s interfaces
classic: permits full system-level access, analogous to a deb or rpm installation.

I was hesitant in changing the confinement setting from strict (the default) to classic, but seeing the new problems that users run into, I think that changing to classic confinement would resolve most if not all existing issues, and give a better end-user experience.

Should I go ahead and start changing confinement from strict to classic? There will be a review and approval process as documented in https://snapcraft.io/docs/reviewing-classic-confinement-snaps, but that is a one-time thing that shouldn't take too long.

[jmooring]

For reference. Installation instructions from https://snapcraft.io:

App	Instructions
vscode	sudo snap install code --classic
atom	sudo snap install atom --classic
sublime	sudo snap install sublime-text --classic
go	sudo snap install go --classic
hugo	sudo snap install hugo

[bep]

Is it possible for people today to use:

sudo snap install hugo --classic

If so, we could educate people about that?

[jmooring]

snap install hugo --channel=extended --classic

Warning: flag --classic ignored for strictly confined snap hugo

[anthonyfok]

I have just submitted a "Request for classic confinement for hugo snap" on the Snapcraft forum at

https://forum.snapcraft.io/t/request-for-classic-confinement-for-hugo-snap/19892

as a step forward to switching to classic confinement, though the Snapcraft Team usually discourages the use of classic confinement unless absolutely necessary, and may instead offer helpful advice and workarounds which would solve our problems without switching to classic confinement. We'll see what happens. Everyone reading this, please feel free to join the discussion over there.

[jmooring]

@anthonyfok, the snapcraft team closed your request for classic confinement. They pinged you several times, then gave up.
https://forum.snapcraft.io/t/request-for-classic-confinement-for-hugo-snap/19892/8

[davidsneighbour]

So, there are people who have not much to do with Go and Hugo that decide if it's worth having Hugo being "confined" to classic mode? That's some kind of "Peter Parker principle" gone wrong. Like @jmooring said above: Why having a snap Hugo? Is there a flatpack package? Is there an appimage package? The principal of a snap package is that it's able to run in it's own environment. Hugo can't. So why keep trying it "officially"? Someone with time and calm at their hands could maintain an unofficial package?

[nobuto-m]

My current and temporary workaround is alias hugo=/snap/hugo/current/bin/hugo which will be able to access to system's go binary.

[jmooring]

This issue was rolled into gohugoio/hugo#9078.