failed to resolve output format "print" from site config

[Edwardiv1]

Following the getting started instructions, I get the following error:

$ docker-compose up
Creating network "mydocs_default" with the default driver
Creating mydocs_site_1 ... done
Attaching to mydocs_site_1
site_1  | Error: from config: failed to resolve output format "print" from site config
mydocs_site_1 exited with code 255

[gwatts]

@Edwardiv1 Have a look at #451 and see if that helps

[LisaFC]

@Edwardiv1 did that solve your problem?

[TianCal]

I had the same problem on Windows. I followed #451 final solution but got
Error: "C:\Users\l\hugo_sites\docsy-example\config.toml:1:1": unmarshal failed: toml: invalid character at start of key: ÿ
while hugo serve

[TianCal]

I succeeded by manully uncommenting github_branch instead of using sed command. Hope that helps

[froboy]

Related to google/docsy-example#166.

I think there's something else going on here. I was able to get things working just fine with docker-compose up --build, but hugo and hugo server fail with

Error: from config: failed to resolve output format "print" from site config

I'm wondering if the config changes are just false positives for some deeper issue, maybe something related to the hugo module or versions? I'm also having this problem locally, but a GitPod instance is not. Here's the info:

GitPod (no problems with hugo server)

gitpod /workspace/openy_docs (main) $ go version
go version go1.18.1 linux/amd64
gitpod /workspace/openy_docs (main) $ hugo version
hugo v0.96.0+extended linux/amd64 BuildDate=unknown

Local:

❯ go version
go version go1.18.2 darwin/arm64
❯ hugo version
hugo v0.98.0+extended darwin/arm64 BuildDate=unknown

I also tried the challenging process of downgrading my local Hugo, but even with the versions identical that didn't resolve the issue on my local.

Commenting out github_branch and removing the print option threw failed to extract shortcode: template for shortcode "blocks/cover" not found, but that also seems like a red herring.

[deining]

Did you run git submodule update --init --recursive? If not, please try and see if this cures your problem.

[froboy]

Tried, didn't help.

❯ git submodule update --init --recursive
❯ hugo server
Error: from config: failed to resolve output format "print" from site config

[domingosbarreto]

I'm having the same issue. The difference is that I'm not using docker, the error occurs in my computer with hugo v0.99.1.
Already, tried all the solutions stated here and #451, and with the same results.
The strange thing is that the first time the error occurred it was while hugo serve was running successfully, and from that onwards I'm unable to run hugo or hugo serve.

[317brian]

I'm having the same issue running Monterey 12.3 on an M1 mac, and it looks like @froboy is running an M1 too based on darwin/arm64. My terminal (iterm2) is set to run Rosetta on.

Colleagues not on M1 macs are not having this issue with the same repo.

• The repo I am having trouble with uses the template method. Tried it before and after running git submodule update --init --recursive.
• Running hugo mod graph gives the same print error.

I cloned an existing Docsy-based site that uses the submodule method as well as created a new site using the submodule method, and they both worked.

Running hugo server on a new Hugo site not using Docsy works

[LisaFC]

OK, that's interesting. The only other Mac-specific issue we had before was about the number of open files:
https://www.docsy.dev/docs/get-started/known_issues/#macos

[317brian]

Ian M on the Write the Docs Slack was able to build my test repo on an M1 mac: https://github.com/317brian/docsy-hugo-module

He's running Hugo 0.96.0 extended on Mac OS 12.4. I'm running Hugo 0.100.1 extended on Mac OS 12.3. I downgraded Hugo but still wasn't able to build. Will try upgrading my OS next

(The code config.toml line was me deleting print from the output options to see what would happen)

Link to the convo:
https://writethedocs.slack.com/archives/C6ELY9E4S/p1654108581501319

[317brian]

Upgrading to Mac OS 12.4 fixed it for me

[chrismetz09]

same, upgrade to Mac OS 12.4 fixed this problem.

[317brian]

So I was actually about to comment @chrismetz09. The issue reoccurred for me with no changes to the repo or to the versions for anything (Hugo, Go, my OS, etc). But after I restarted my machine, it built again.

What I noticed was that hugo server had some additional outputs that aren't typically there when I ran the command for the first time after the restart:

❯ hugo server
hugo: downloading modules …
hugo: collected modules in 13647 ms
Start building sites …

These aren't there on subsequent successful builds

[amirootyet]

Can confirm that this issue occurred for me when using a Mac (i7) with Monterey 12.3.1. After looking at the comments here, I upgraded my Mac OS to 12.4 and this issue was automatically resolved. Leaving this comment here for other Mac users who maybe facing this issue.

[LisaFC]

Good to hear people are getting it working with upgrade. Should we add this as a known issue to our docs or is it something sufficiently short-lived with Mac versions that most people won't experience it?

[chrismetz09]

@317brian, hugo server stopped working and instead received the problematic ..config: failed to resolve output format "print" from site config.. Performed reboot and results are:

TestMermaidK8s git:(master) ✗ hugo server -D
hugo: downloading modules …
hugo: collected modules in 12032 ms
Start building sites …
hugo v0.93.0-07469082+extended darwin/amd64 BuildDate=2022-02-28T08:30:42Z VendorInfo=gohugoio

[317brian]

Yup, I've had the print error continue to show back up every few days. I'm not sure why a restart fixes it. A colleague has also encountered this issue, but she's not on an M1. Running Hugo/docsy in a docker container on her machine worked.

[amirootyet]

For everyone's awareness, while I initially thought the fix for this seemingly random Mac issue is an OS upgrade, that is not the case. This error creeps up randomly after a few weeks on my machine and then a system restart fixes it.

The reason it worked before was because I did a system restart as part of the OS upgrade process. Not familiar enough with Hugo to guess why this error creeps up now and then and why a restart fixes it. But this problem started with the "Docsy as a Hugo Module" move. Didn't have this issue when I was using Docsy as Git submodule.

[domingosbarreto]

Did you find a solution for this? I'm using Windows and restart doesn't fix. Since the error appeared the first time, I'm unable to do anything. And running a new Hugo site that does not uses Docsy works.

[ivan3bx]

I've only been using docsy a few weeks, but encountered this same error. I found reference to "failed to resolve output format" elsewhere (external link), and I was able to fix with the following (Mac Mini, i7 MacOS 12.4, uptime 18+ days):

1. Removed $TMPDIR/hugo_cache/ (per the troubleshooting article above. (NOTE: I needed to "sudo" this.)
2. Re-ran hugo serve which worked fine. (i.e. no reboot)

Given the above, there might be a correlation between people resolving this via a reboot, and the OS doing housecleaning of the TMP dir as part of a reboot. Hard to say. Given how I was able to fix it, suggests this issue may have something to do with hugo's handling of its mod cache, or Mac's handling of tmp dirs.

[LisaFC]

Should we add this as a known issue in the docs, as it seems to crop up fairly frequently?

[wrex]

I'm biased from having just run into this, but I'd say it's worthy of a mention somewhere in the docs.

My bad for not reading the entire thread: I missed @ivan3bx's explanation in #805 (comment)

This does indeed appear to be the precise issue.

[rachfop]

Similar to ivan3bx, I did the following to resolve this issue:

sudo rm -rf $TMPDIR/hugo_cache/

Then rerun the Hugo server command.

hugo server -D

[JamesHaskell]

Deleting the cache as per rachfop worked for me, and I did not have to change the config or any of the other suggestions. Thanks Patrick!

[froboy]

Updating submodules did not work for me... ``` ❯ git submodule update --init --recursive ❯ hugo server Error: from config: failed to resolve output format "print" from site config ``` But the cache clear as per #805 (comment) did work. Yay!

…

On Mon, May 16, 2022 at 5:08 PM Andreas Deininger ***@***.***> wrote: Did you run git submodule update --init --recursive? If not, please try and see if this cures your problem. — Reply to this email directly, view it on GitHub <#805 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB2E6KMPBSJPWM2UGGCCYDVKLBNDANCNFSM5KASIR6A> . You are receiving this because you commented.Message ID: ***@***.***>

[deining]

I ran into the same issue today. This helped me to overcome the problem:

In your config.yaml, locate this section:

outputs:
  home: [HTML]
  page: [HTML]
  section: [HTML, RSS, print]

Remove the print output format:

outputs:
  home: [HTML]
  page: [HTML]
  section: [HTML, RSS]

The error should be gone, so you can continue with your installation. Once finished, you can add the print format again. This time, no error should occur any more.

For more background, please also have a look at the dicussion comment on issue 535 and on this discussion thread at hugo's discourse forum.

[vinceyoumans]

I am running mac os 13.2.1 on M1 chip... but getting this error.

[froboy]

It's been a minute, but I ran into this while setting up Heading self-links as per #1831.

Change detected, rebuilding site.
2024-06-18 16:14:09.335 -0500
Template changed WRITE|CHMOD   "<project>/layouts/_default/_markup/render-heading.html"
WARN 2024/06/18 16:14:09 found no layout file for "html" for layout "search" for kind "page": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
WARN 2024/06/18 16:14:09 found no layout file for "html" for kind "home": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
WARN 2024/06/18 16:14:09 found no layout file for "html" for kind "section": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
WARN 2024/06/18 16:14:09 found no layout file for "html" for kind "term": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
WARN 2024/06/18 16:14:09 found no layout file for "html" for kind "page": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
WARN 2024/06/18 16:14:09 found no layout file for "print" for kind "section": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
<many duplicate WARNs removed>

And then the project failed to build, even when I removed the new render-heading.html. #805 (comment) fixed it again.