Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the "is this a Hugo Module" logic more lenient #6299

Closed
espadrine opened this issue Sep 2, 2019 · 4 comments · Fixed by #6302

Comments

@espadrine
Copy link

commented Sep 2, 2019

Reproduction

  1. Start with a folder in which hugo server does serve the website.
  2. touch go.mod
  3. hugo server

Expected behavior

Hugo serves the website still.

Actual behavior

Hugo fails to serve the website with the following error:

go: cannot determine module path for source directory ~/go/src/example.com/nuclear/reactor (outside GOPATH, no import comments)
Error: failed to download modules: go command failed: go: cannot determine module path for source directory ~/go/src/example.com/nuclear/reactor (outside GOPATH, no import comments)

(More commonly, the go.mod will not actually be empty; the render may then fail with the message go: error loading module requirements for instance, which feels like it ought to be decoupled.)

Use case

We have a project where we maintain the documentation alongside the code. Had we developed the project in any other language than Go, we would have had no issue. But the project is in Go, and therefore we now started to work on supporting Go modules, which required having a go.mod. Old versions of Hugo worked fine (such as v0.54.0), but new versions don't.

References

Hugo Static Site Generator v0.57.2/extended darwin/amd64 BuildDate: unknown

@bep

This comment has been minimized.

Copy link
Member

commented Sep 2, 2019

I suggest you move your site into its own root.

@espadrine

This comment has been minimized.

Copy link
Author

commented Sep 3, 2019

It does look pretty heavily hardcoded. IIUC it would be subtle to detect whether the go.mod is a Hugo module or something else. Oh well.

Thanks for your work on Hugo! You may close this issue if you believe it would be impossible to fix.

@bep

This comment has been minimized.

Copy link
Member

commented Sep 3, 2019

You may close this issue if you believe it would be impossible to fix.

I didn't say that, I just gave you a tip for a workaround.

What we cannot currently do is change it to hugo.mod or something (that would be nice, but go.mod is hardcoded in 123 different places in the Go source).

What we could probably do is to improve the "is this a Hugo Module" logic.

Currently, it is simply: Is there a go.mod file in the project.

We could probably change that to "go.mod + any module imports (e.g. theme imports with module paths)".

@bep bep added this to the v0.58 milestone Sep 3, 2019

@bep bep changed the title Hugo fails to render when a go.mod file is present Make the "is this a Hugo Module" logic more lenient Sep 3, 2019

@bep bep added the Enhancement label Sep 3, 2019

bep added a commit to bep/hugo that referenced this issue Sep 3, 2019
Make the "is this a Hugo Module" logic more lenient
Now we only try to load modules via Go if there is one or more modules imported in project config.

Fixes gohugoio#6299

@bep bep closed this in #6302 Sep 3, 2019

bep added a commit that referenced this issue Sep 3, 2019
Make the "is this a Hugo Module" logic more lenient
Now we only try to load modules via Go if there is one or more modules imported in project config.

Fixes #6299
@espadrine

This comment has been minimized.

Copy link
Author

commented Sep 3, 2019

Nicely done! Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.