cannot find package hcl/hcl/printer

[ionutnechita]

cannot find package "github.com/hashicorp/hcl/hcl/printer" in any of:
/usr/lib/go-1.16/src/github.com/hashicorp/hcl/hcl/printer (from $GOROOT)
/root/go/src/github.com/hashicorp/hcl/hcl/printer (from $GOPATH)

[jmoodie2002]

Same issue while trying to install with cobra. Cobra posted solution has no effect. Ubuntu 18.04:

export GO111MODULE=on
go get -u github.com/spf13/cobra/cobra

package github.com/hashicorp/hcl/hcl/printer: cannot find package "github.com/hashicorp/hcl/hcl/printer" in any of:
/usr/lib/go-1.10/src/github.com/hashicorp/hcl/hcl/printer (from $GOROOT)
/home/xxx/go/src/github.com/hashicorp/hcl/hcl/printer (from $GOPATH

[apparentlymart]

Hi @ionutnechita,

I'm sorry you've encountered this problem.

Based on your error messages, it seems like you are using Go 1.16 in the legacy GOPATH mode rather than in the current Go Modules mode. Because GOPATH mode doesn't understand versioning, it's unable to distinguish between HCL version 1 and HCL version 2, and so it's failing to access what looks to be a HCL version 1 dependency.

There's some more details on what's going on here in the Version Selection wiki page, but I think a shorter answer to this is that if you migrate your project to use Go Modules instead of the legacy GOPATH mode then installing those HCL version 1 packages should work.

Due to technical constraints of the modern Go toolchain, we can no longer support the legacy GOPATH mode for HCL 1 without continuing the high-friction workarounds we employed for the first year after publishing major version 2, which have been a significant cause of confusion for contributors. For that reason, I'm going to close this issue.

I understand that some are getting HCL 1 as a dependency only indirectly via Viper (possibly Viper also indirectly via Cobra); unfortunately various parts of the Go ecosystem are moving gradually and independently to the modules system and so for some people HCL is the first thing in their dependency tree to begin requiring Go Modules, and I understand that is inconvenient but sadly if it were not this codebase then before too long it would be some other codebase because GOPATH mode is being phased out. 😖 The Viper team has also produced a troubleshooting guide which includes this problem at the time of writing, and they are echoing my suggestion to upgrade to Go Modules.

---

@jmoodie2002 I see in your output that you are using Go 1.10, which I believe predates the introduction of the GO111MODULE environment variable (the 111 in it refers to Go 1.11). In your case, I think you'll need to upgrade to a newer version of Go in addition to enabling modules mode; Go 1.11 would be the minimum, but Go Modules was still experimental in that Go version and so you may encounter bugs and workflow friction that were addressed in later Go releases before Go Modules became the recommended solution.

[misteruly]

With GoPath, you can also avoid this mistake??

[lordvalium]

Could not solve the problem. v2 seems to be very inconvenient