go mod tidy seems to automatically get v1.2.0

[ds-281]

Hello,

It seems that using uconfig causes go mod tidy to fetch v1.2.0 by default. At the very least, on go1.21.5 linux/amd64.

user@hostname > /tmp/foo > vim main.go # here just copy/paste the first full example from the README and remove redis/database references 
user@hostname > /tmp/foo > go mod init foo
go: creating new go.mod: module foo
go: to add module requirements and sums:
	go mod tidy
user@hostname > /tmp/foo > go mod tidy
go: finding module for package github.com/omeid/uconfig
go: found github.com/omeid/uconfig in github.com/omeid/uconfig v1.2.0
user@hostname > /tmp/foo > go version
go version go1.21.5 linux/amd64

This causes the version of uconfig to be somewhat outdated. I noticed this because the USAGE column was nowhere to be found upon calling .Usage() and decided to investigate a bit. Editing the go.mod to point towards 0.5 instead naturally works.

[omeid]

I think it is potentally related to golang/go#39007.

I have now pushed a new tag for v1.2.0 with the retraction that was pushed earlier on, and see if that covers it.

[ds-281]

It might be. The tag pushed however did not fix it on my end, sadly.

user@hostname > /tmp/foo > go build
# foo
./main.go:23:35: too many values in struct literal of type struct{Path string; Unmarshal file.Unmarshal}

This happens in older versions of uconfig, where the optional flag for uconfig.Files wasn't present.

(note: I have made sure to manually remove [...]/pkg/mod/github.com/omeid/uconfig@v1.2.0 beforehand, it doesn't seem to be a cache issue)

[omeid]

I had to push a higher version that retracts 1.2.0 as well as itself (1.2.1). It should be fixed now.

[ds-281]

Yup, that did it. Thanks!