Besides Hugo’s default Markdown renderer Goldmark, there’s also support for other content formats including Pandoc. Theoretically. In practice, I can’t get the snap version of Hugo to use the Pandoc binary. The error message is not overly helpful either:
Building sites … ERROR 2019/12/20 14:15:42 pandoc not found in $PATH: Please install.
Leaving pandoc content unrendered.
I think this is due to the strict security model of snaps (confinement). Installing the Hugo snap in --classic mode is not an option either.
If Pandoc were packaged as a snap, too, then it could offer an appropriate slot that other snaps including Hugo could plug into. But since this is not the case, I wonder if it wouldn’t be best if the snap package just included its own copy of the Pandoc binary (and maybe Asciidoctor and RST, too)?
The error message is very helpful. $PATH is the directory you are in when you type and run hugo. So if pandoc does not work in that directory, it can’t be found. I don’t want to go to search now, but if you type which pandoc (and I assume you are on Linux) what comes up? If it’s some exotic place you could do a symlink to /usr/bin/pandoc and it would be in the path. If it is not found you probably have it installed somewhere via npm or yarn and the bin path of that tool needs to be in your path. They (npm, yarn) typically have a page in their documentation about “putting it in the path”.
The easiest might be to install pandoc locally into your repository. Might work out of the box then.
And my whole answer needs to be read with the knowledge, that I don’t know what pandoc is or how it’s installed to your computer.
No, it’s not. It implies the cause of the problem is that Pandoc can’t be found in $PATH and thus is completely agnostic about the additional confinement imposed on snap packages.
if you type which pandoc (and I assume you are on Linux) what comes up?
Pandoc is installed in /usr/bin/pandoc on my system (I’ve installed in through the official DEB package; I’m on Ubuntu 16.04).
The easiest might be to install pandoc locally into your repository. Might work out of the box then.
Even if that worked, I wouldn’t like such a workaround at all (duplicating the Pandoc executable for every Hugo site).
Well then install Hugo without using Snap. You complain about a Snap security feature here, not about a Hugo bug. Download Hugo as deb-package and install the same way you install the tools. You will complain about the now missing auto-update on new Hugo versions though. I solved this by watching new releases on the Hugo Github page.
What probably would work is putting the binaries into a repository and use that as module for all your website repos. But that’s even worse manageable in regards to updates and versions.
You complain about a Snap security feature here, not about a Hugo bug.
Well, as I see it I complain about a bug that’s specific to the Hugo snap package. Right now it seems impossible to use an official Hugo feature, namely rendering other content formats, with the snap version of Hugo.
As far as I understand it, the author of the Hugo snap package has means to solve this problem by either
offering a version with classic confinement so that users could opt-in to go without the additional security of strict confinement for the benefit of a working Pandoc/Asciidoctor/RST support.
shipping its own copies of the Pandoc/Asciidoctor/RST binaries and not changing anything regarding confinement. I guess this would be my favoured solution.
I solved this by watching new releases on the Hugo Github page.
That’s a quite creative interpretation of the term “solution”…
shipping its own copies of the Pandoc/Asciidoctor/RST binaries and not changing anything regarding confinement. I guess this would be my favoured solution.
The problem is, that this would increase the size of the Snap package massively if all extensions would be included. It makes more sense to write the documentation so, that the deficiencies of the Snap package become clear. The way I see it now all default features are included. If one needs more, they need to install a different version.
I remember in the release notes when @bep released the hugo-extended version the first time he went into depth on this topic.
Not sure about the classic method. If that is a feature that stays within Snap then this might be the better solution for these this specific cases. (my opinion)
Yes. But this is to some degree inherent to the security model of Snap, Flatpak and Co. They don’t share (and thus don’t need access to) system ressources as (much as) classic software packages do for the price of significantly increased storage space requirements.
Maybe the snap version that would ship the mentioned external binaries could be offered in a separate track?
