Closed ashtonian closed 1 year ago
Do you have a reproduction mechanism I can use?
internal/ast
was removed in commit e195b58fd0a5440a82ade22e8f6d2da4227b5edf, which was part of v2.0.6 released a year ago. Quick grep shows no mention of internal/ast
in v2.1.0.
I tried to reproduce the issue with docker, but the upgrade path seems to work:
~$ docker run -ti golang
root@d1910a3c2fe9:/go# mkdir app
root@d1910a3c2fe9:/go# cd app
root@d1910a3c2fe9:/go/app# go mod init example.com/app
go: creating new go.mod: module example.com/app
root@d1910a3c2fe9:/go/app# go get github.com/pelletier/go-toml/v2@v2.0.5
go: downloading github.com/pelletier/go-toml/v2 v2.0.5
go: added github.com/pelletier/go-toml/v2 v2.0.5
root@d1910a3c2fe9:/go/app# cat go.mod
module example.com/app
go 1.21.1
require github.com/pelletier/go-toml/v2 v2.0.5 // indirect
root@d1910a3c2fe9:/go/app# echo 'package main
> import "github.com/pelletier/go-toml/v2"
> import "fmt"
>
> func main() {
> fmt.Println(toml.Marshal)
> }
> ' > main.go
root@d1910a3c2fe9:/go/app# go mod tidy
go: downloading github.com/stretchr/testify v1.8.0
go: downloading github.com/davecgh/go-spew v1.1.1
go: downloading github.com/pmezard/go-difflib v1.0.0
go: downloading gopkg.in/yaml.v3 v3.0.1
root@d1910a3c2fe9:/go/app# cat go.mod
module example.com/app
go 1.21.1
require github.com/pelletier/go-toml/v2 v2.0.5
root@d1910a3c2fe9:/go/app# go mod vendor
root@d1910a3c2fe9:/go/app# go get -u
go: downloading github.com/pelletier/go-toml/v2 v2.1.0
go: downloading github.com/pelletier/go-toml v1.9.5
go: downloading github.com/stretchr/testify v1.8.4
go: upgraded github.com/pelletier/go-toml/v2 v2.0.5 => v2.1.0
root@d1910a3c2fe9:/go/app# go mod vendor
root@d1910a3c2fe9:/go/app# cat go.mod
module example.com/app
go 1.21.1
require github.com/pelletier/go-toml/v2 v2.1.0
root@d1910a3c2fe9:/go/app#
Given how old this reference is, this sounds like a cache problem. I haven't used vendoring with go in a long time, but maybe something like go clean -modcache -cache
could help?
Thank you for the quick reply! I was able to move it forward by removing it entirely from vendor/project, clearing the cache and reapplying. I don't fully understand what is going on but seems to be a cache issue on the local machine. I've run into this with some other libraries that change their module path for a library dependency. Very weird, hopefully it gets matured out of the vendor/module functionality.
Thanks again.
Glad to hear it ended up working!
Describe the bug I reference go-toml in some files in a large project. I'm using vendoring. I've deleted all references to that package and go-toml from the vendoring and it still seems to fail so I think there is a bad reference ? Running
go get -u all
returns: