On behalf of Hugo authors, I would like to request classic confinement for Hugo, a fast static website generator written in the Go programming language.
We have been using confinement:strict since @dholbach generously gave us the initial version of snapcraft.yaml in September 2016. However, as Hugo grows in features and popularity, and with the Snap being promoted as the easiest and preferred installation method, more and more users run into issues such as
Thanks for your post. I would suggest we keep your snap under strict confinement so you can enjoy all the benefits of a stable runtime environment and we help you to (hopefully) overcome the issues your snap users are experiencing. Please remember classic snaps are not installable on Ubuntu Core devices and also run in the global mount namespace, which means great care must be taken for the snap to work reliably across distributions (I see you have users running Manjaro).
Have you tried snappy-debug when troubleshooting issues? It could help you identify missing interfaces you could plug while keeping your snap strict. If you run into problems, post the snappy-debug output here along with your questions and we are happy to help.
I am not very familiar with Go modules, let me do a bit of research and will back to you as soon as possible. Meanwhile, it seems the issue your users are reporting is “Error: we found a go.mod file in your project, but you need to install Go to use it”, can you please confirm?
I am assuming #2 could be fixed with an updated node.js as you stated.
Access to arbitrary files on the system is typically not a justification for classic confinement since the the home and removable-media interfaces provide typical locations for users to operate in. Have you considered the use of personal-files, system-files, or even snap layouts? What specific locations are still not covered by those?
Dependent software only available on host also falls under the unsupported category. You can easily include relevant packages from the Ubuntu archive via stage-packages, could this be an option?
If I read correctly in https://gohugo.io/hugo-modules/use-modules/ is it a fair statement to say that hugo now requires recent version of go available and hugo mod essentially leverages Go Modules to setup building blocks for your hugo site?
If so, and considering that you need a recent enough version of go, how feasable would it be to just add Go into the Hugo snap?
This seems to have been covered in the issue, my proposal for the previous point is similar to what you have done on this one.
This is true, adding a couple of more interfaces would allow for access to /media and such.
I personally use hugo and would prefer it to stay strict knowing what the caveats are, but if any Go is a goal (and not an implementation detail), then yeah, classsic is the way to go. Same would apply for node.
I am not sure if channel tracks can be assigned classic and have the “main” tracks as strict, that is a potential alternative for people wanting unconfined.
Looking at the documentation, it doesn’t look like Hugo is just using the Go module system as a data distribution mechanism rather than to compile anything.
It’s possible that it would work with only part of the Go toolchain available, but it also means that you might end up having Hugo invoke git to clone a module (if not going through the module proxy), which may also end up using ssh auth. It would seem difficult to get this working reliably with strict confinement, assuming it is possible.
@anthonyfok since we’ve not heard back from you, we are removing this request from our review queue. When you have more time to respond, simply do so here and we can add the request back to the queue. Thanks
I am not entirely sure what more information you require from me; I believe the conversations at https://github.com/gohugoio/hugoDocs/issues/1222 make it pretty clear from multiple end users requiring Hugo to use classic confinement. If there are still unanswered questions, may I invite them to answer here?
Regarding this request, hugo could be seen as perhaps a compiler of sorts, and so could fit within that existing category for classic confinement as per Process for reviewing classic confinement snaps - @anthonyfok to be granted classic confinement it is not sufficient to just outline reasons why something doesn’t work with strict confinement - a snap also has to fit within one of the existing categories - can you please comment on this?
Thanks @Igor, classic confinement granted for hugo - this is now live (ie future uploads of hugo which specify confinement: classic will pass automated review)
Note existing users of the snap will not be automatically upgraded to the classic version - so you should publish an update which is still strictly confined that prompts them to manually refresh to get the classic version (or you could perhaps use a separate track for classic…?)
ie. users will need to manually run:
snap refresh --classic hugo