Open gcushen opened 1 month ago
Do you have a simple example that shows the behaviour you describe?
I am unable to reproduce the problem as described.
git clone --single-branch -b hugo-github-issue-12555 https://github.com/jmooring/hugo-testing hugo-github-issue-12555
cd hugo-github-issue-12555
Terminate all network connections, then...
hugo server
You should see 3 articles listed on the home page.
The current logic is rather simple (taken from memory): If the main project has a _vendor
dir and that directory resolves all the modules defined in the site config, then all is fine and dandy. All other cases will be handed to go
which may or may not ask the internet for advice.
To reproduce:
hugo new site test
cd test
echo -e "module test\ngo 1.19\nrequire github.com/gcushen/private-go-module v0.0.0-20240506024847-96f2f37c71bb" >> go.mod
echo -e "\n\n[[module.imports]]\npath = 'github.com/gcushen/private-go-module'" >> hugo.toml
mkdir -p '_vendor/github.com/gcushen/private-go-module'
echo -e "# github.com/gcushen/private-go-module v0.0.0-20240506024847-96f2f37c71bb" >> ./_vendor/modules.txt
echo 'title: Test' >> '_vendor/github.com/gcushen/private-go-module/config.yaml'
hugo server
This results in the following error and inability to view the site even though the module is vendored:
Error: command error: failed to load modules: failed to download modules: failed to execute 'go [mod download -modcacherw]': failed to execute binary "go" with args [mod download -modcacherw]: go: github.com/gcushen/private-go-module@v0.0.0-20240506024847-96f2f37c71bb: invalid version: git ls-remote -q origin in /tmp/hugo_cache/modules/filecache/modules/pkg/mod/cache/vcs/9c89562b4e8d021544f76a9645661b038d05b9e1ad5a17389373f2b4ff435feb: exit status 128:
remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/gcushen/private-go-module/'
*errors.errorString
This can be a common use case where you have a developer creating a modular Hugo project for a business stakeholder or client, but only the developer should have access to the private Hugo module in the repo, so the module is vendored for the stakeholder/client.
@gcushen that's not a "simple example".
@gcushen that's not a "simple example".
It's a fully reproducible example of importing an arbitrary private Hugo module in only 8 steps, based on the minimally reproducible hugo new site
command. How would you suggest to make it simpler?
@gcushen
How would you suggest to make it simpler?
OK, maybe "not simple" wasn't the correct way to describe your example. But manually constructing the Go module/vendoring setup (example line below) is not the real thing and filled with many sources of error.
echo -e "# github.com/gcushen/private-go-module v0.0.0-20240506024847-96f2f37c71bb" >> ./_vendor/modules.txt
That said, I tested your example, and it runs fine on my MacBook. I also tried to delete the _vendor
folder, a new build triggers a "Please make sure you have the correct access rights and the repository exists", which makes sense as this is a private repo.
Can you
env | grep HUGO_
), e.g. HUGO_IGNOREVENDORPATHS
.hugo version
.Also, is this something only you experience or is this something that's reported from your end users?
If you're able to insert some debug prints in Hugo code, you can check if this condition triggers or not (and possibly also why):
Currently, Hugo can attempt to download a module from GitHub even if it has been downloaded to the
_vendors
folder.The expected behavior is that Hugo checks if the module in
go.mod
has been downloaded to the_vendors
folder before attempting to access the internet.This can be a common use case where you have a developer creating a modular Hugo project for a business stakeholder or client, but only the developer should have access to the private Hugo module in the repo, so the module is vendored for the stakeholder/client.
As a workaround, if the private Hugo module is deleted from
go.mod
then Hugo will use the vendored module. Ideally, it should not require the workaround of the stakeholder/client deleting the module fromgo.mod
as then theirgo.mod
is out of sync with the developer's copy.What version of Hugo are you using (
hugo version
)?Does this issue reproduce with the latest release?
Yes