How’s the snap work going? Do you need any help? I had some thoughts.
An extended channel shouldn’t be needed with Snaps. The whole point is that they confine the program, including any libraries a binary might need. Everything should be encapsulated within the .snap and SnapD. The fact that Hugo now requires CGO should have to be dealt with internally, but shouldn’t affect users.
Is there a requirement to build the snap with the Go plugin? Hugo already builds binaries with GoReleaser. You can drastically reduce the number of lines in Snapcraft.yaml if you just packaged the binaries that GoReleaser spits out.
From Snapcraft.yaml, `version: “0.49-DEV”, you can get the version number dynamically from Hugo itself.
Should Pygments be removed from the snap since Hugo has switched over to Chroma?
Sorry for the delay in fixing Hugo snaps for 0.48 and now 0.49. Had been very busy, but I really should try to fix the snap build to make the latest Hugo available on Snap.
But to answer your question:
IIRC, It was a deliberate decision, especially by @bep, to keep the vanilla (no LibSass) and “extended” (with LibSass) versions separate, and the use of the “extended” track was recommended to me by the gurus on forum.snapcraft.io. See:
The original snapcraft.yaml given to us by Daniel Holbach who developed Snap in Canonical already uses the Go plugin. The Hugo snap is also built for s390x (IBM System z) and ppc64el (PowerPC64 Little-endian) platforms which we currently do not provide with GoReleaser.
I know that both Choco and Homebrew for Hugo grab the GoReleaser pre-built binaries from GitHub, but for better or for worse, that is not the Snap way.
That’s an interesting idea! It wasn’t possible to set the version dynamically in September 2016 when it was first gifted to us by Daniel Holbach, but it seems such a feature in the name of version-script has been added as new feature around mid-2017. See:
And maybe not only the version but also the grade, but we’ll need to investigate. I believe though that @bep already has this “change the version number in snapcraft.yaml” automated, so it is not urgent to “fix” snapcraft.yaml, but yes, worthy to look into.
I thought about that too, but I am sure there are bound to be some users out there who haven’t made the switch from Pygments to Chroma, so, maybe I will wait another year or two, and perhaps announce its deprecation here so people would know.
Which I can understand for the raw binary but within snaps I don’t see the advantage. Makes it more difficult to build without any benefit.
Yeah I’m familiar with him from the Ubntu team. Snapcraft is similar to Hugo in that it has rapid development. There’s several practices (like the Snapcraft.yaml file in the root directory) that’s outdated now. I’ve been trying to help with Docs over on their site but they now run two completely separate Docs repositories and it’s very time consuming.
Ah very true. Those extra binary architectures is a *very good reason to build via the Go plugin on their build release infrastructure. You wouldn’t be able to do it on CircleCI either so I understand the choice there now.