Hugo Modules without GitHub

support
1

Hello,

I am a seasoned developer but new to Hugo and trying to get my head wrapped around Hugo modules. We are looking for a way to use Hugo Modules with either local file paths and/or our internal git repos instead of using GitHub.

Is it as simple as replacing the module reference with our internal git link?

I am hoping / expecting that there is a simple solution to avoid what is looking like a hard GitHub dependency.

Thanks in advance

2

Sure. Go-Modules somehow always have to include Github for some reason. But, you can always add a replace configuration rule to your go.mod.

module github.com/some-user/some-package

replace github.com/some-user/some-package => /my/local/path/to/the/module

require (
	... automatic requires
)

I am not 100% sure if at any point Golang wouldn’t try to go to Github to verify something. You might want to read deeper into the whole replace functionality. It probably makes sense to create some form of private Github repo for the path required. You can do “deeper paths” in the form of all your modules in a single repository. The modules would still need a go.mod each and those can look like github.com/some-user/some-package/modules/my-module (for the module line in go.mod) where modules/my-module/go.mod is the path to the go.mod file within your mono-repo.

Last note: a lot of GoHugo’s module functionality is Golangs module functionality with a hugo command in front of them. So whatever they have in their documentation might/probably will apply to GoHugo too.

1 Like
3

Thanks for the tip…

Using replace feels a little cludgy and ick however if that is how the system works it’s how it works. No use in fighting it, just need to determine if / how our strict SCA rules will mesh with that reality.

Will do a little further digging into go modules directly to try and break through this brain-blocker.

Owe you one… Thanks.

4

A setup I think work OK is something what you see on

In the setup above, if I want to make a theme change, I

  • HUGO_MODULE_WORKSPACE=hugo.work hugope server --ignoreVendorPaths "**"
  • Edit theme … Push theme
  • Update theme: hugo mod get github.com/gohugoio/gohugoioTheme
  • Vendor: hugo mod vendor

The mean reason we do this for the Docs repo is so we can include the full source in the GitHub source distributions, but it also works well in private repo setups, as only the one running “hugo mod vendor” needs access to the repo.

One other alternative would be to put your “Hugo modules” inside what’s configured as the themesDir in the project (default project/themes).

1 Like
5

Thanks for the link Bep… Will give the links a read and see what might be possible.

Once we get a test set up we can do some isolated wireshark monitoring to see how the system behaves under different configurations and verify any connection requests or potential risk for data or meta-data exfiltration.

Appreciate the info… thanks again.

6

OK, the full list of module settings are

One option could be to set the proxy option, which would make sure that modules are never fetched from GitHub. There are some fairly simple to set up Go Module Proxy servers out there.

7

Bep,

Again, thank you for the links. Have been diving into using our old bootstrap theme as a baseline and think we may have a workable solution.

Still have some testing to do however using a baseline “hugo new theme” then starting to dive into making it work with existing templates might just do the trick. Little more work / time than we initially expected however hugo makes that work easy.

Have a much better understanding now on how the links between go modules and hugo modules function.

Appreciate the help

Edit: Came across this reference while looking into Go modules. As mentioned by others above, Hugo Modules are effectively Go Modules and Go Modules use the underlying git configuration as well.

Thought the GOPRIVATE reference might help someone so adding here.

Go Private Modules using GOPRIVATE env variable