how to purge invalid tags from GOPROXY?

[Sebastien Binet]

hi there,

I've forked a fork of a Go package (github.com/jung-kurt/gofpdf).
But as the modus operandi of such a thing is rather unwieldy in github
(PRs would always be created by default against the original package
instead of my fork), I've deleted the forked repo, created a new repo
with the same name and pushed the original git tree there.

so now, my PRs are, by default against my fork, which is great.

unfortunately, I've also decided that my fork would start at v0.1.0
(what would be the last commit from the old gofpdf package) while the
original package was at v1.4.2

and it seems GOPROXY cached it somehow:

$> docker run --rm -it golang
root@clrinfopc42:/go# cd src/
root@clrinfopc42:/go/src# mkdir foo
root@clrinfopc42:/go/src# cd foo/
root@clrinfopc42:/go/src/foo# go mod init foo
go: creating new go.mod: module foo
root@clrinfopc42:/go/src/foo# go version
go version go1.16.5 linux/amd64
root@clrinfopc42:/go/src/foo# cat >> go.mod

require github.com/go-pdf/fpdf v0.3.1
^C
root@clrinfopc42:/go/src/foo# cat >> main.go
package main

import _ "github.com/go-pdf/fpdf"

func main() {}
^C

root@clrinfopc42:/go/src/foo# go mod tidy
go: downloading github.com/go-pdf/fpdf v0.3.1

root@clrinfopc42:/go/src/foo# go build -v
github.com/go-pdf/fpdf
foo

root@clrinfopc42:/go/src/foo# go get -u -v github.com/go-pdf/fpdf@latest
go: downloading github.com/go-pdf/fpdf v1.4.2
go get: github.com/go-pdf/fp...@v0.3.1 updating to
github.com/go-pdf/fp...@v1.4.2: parsing go.mod:
module declares its path as: github.com/phpdave11/gofpdf
but was required as: github.com/go-pdf/fpdf

root@clrinfopc42:/go/src/foo# go get -x -u -v github.com/go-pdf/fpdf@latest
# get https://proxy.golang.org/github.com/@v/list
# get https://proxy.golang.org/github.com/go-pdf/fpdf/@v/list
# get https://proxy.golang.org/github.com/go-pdf/@v/list
# get https://proxy.golang.org/github.com/@v/list: 410 Gone (0.107s)
# get https://proxy.golang.org/github.com/go-pdf/fpdf/@v/list: 200 OK (0.107s)
# get https://proxy.golang.org/github.com/go-pdf/@v/list: 410 Gone (0.107s)
go get: github.com/go-pdf/fp...@v0.3.1 updating to
github.com/go-pdf/fp...@v1.4.2: parsing go.mod:
module declares its path as: github.com/phpdave11/gofpdf
but was required as: github.com/go-pdf/fpdf

of course, it works if I give the explicit new tag of go-pdf/fpdf:

root@clrinfopc42:/go/src/foo# go get -u -v github.com/go-pdf/fp...@v0.4.0
# get https://proxy.golang.org/github.com/@v/v0.4.0.info
# get https://proxy.golang.org/github.com/go-pdf/fpdf/@v/v0.4.0.info
# get https://proxy.golang.org/github.com/go-pdf/@v/v0.4.0.info
# get https://proxy.golang.org/github.com/@v/v0.4.0.info: 410 Gone (0.223s)
# get https://proxy.golang.org/github.com/go-pdf/@v/v0.4.0.info: 410 Gone (0.223s)
# get https://proxy.golang.org/github.com/go-pdf/fpdf/@v/v0.4.0.info: 200 OK (0.226s)
go: downloading github.com/go-pdf/fpdf v0.4.0
# get https://proxy.golang.org/github.com/go-pdf/fpdf/@v/v0.4.0.zip
# get https://proxy.golang.org/github.com/go-pdf/fpdf/@v/v0.4.0.zip: 200 OK (0.370s)
# get https://proxy.golang.org/github.com/go-pdf/fpdf/@v/list
# get https://proxy.golang.org/github.com/go-pdf/fpdf/@v/list: 200 OK (0.029s)
[...]
go get: upgraded github.com/go-pdf/fpdf v0.3.1 => v0.4.0


any idea how one could purge the tags (coming from {jung-kurt,phpdave11}/gofpdf?
I understand that comes a bit at odds with the way the GOPROXY ledger is
supposed to work though...

any idea on how to work around that?
thanks.

cheers,
-s

[Jay Conrod]

Hi Sebastien, once a version is in proxy.golang.org, it usually can't be removed. This is important to ensure that builds continue working when a repository disappears upstream.

You may want to publish a new version with a retract directive in go.mod, marking the earlier versions as invalid. In Go 1.16 and higher, the go command won't automatically upgrade to a retracted version. The version containing the retractions may retract itself. Retract Module Versions is an interactive tutorial explaining how to use this feature.

Even with retractions in place, you won't be able to reuse the old version numbers. They'll be hidden, but still available to any users that depend on them.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CCCK5I3B9536.1RAC82P987RAU%40zoidberg.

[Dan Kortschak]

On Wed, 2021-06-30 at 15:45 -0700, 'Jay Conrod' via golang-nuts wrote:
> Hi Sebastien, once a version is in proxy.golang.org, it usually can't
> be removed. This is important to ensure that builds continue working
> when a repository disappears upstream.
>
> You may want to publish a new version with a retract directive in
> go.mod, marking the earlier versions as invalid. In Go 1.16 and
> higher, the go command won't automatically upgrade to a retracted
> version. The version containing the retractions may retract
> itself. Retract Module Versions is an interactive tutorial explaining
> how to use this feature.
>
> Even with retractions in place, you won't be able to reuse the old
> version numbers. They'll be hidden, but still available to any users
> that depend on them.

It looks to me like the retraction mechanism cannot be used here since
the retraction must be in a version number higher than the retracted
version, but here the author wants to not have a version v1. If
retraction were also based on time (maybe only for specific cases where
retracting by a v0 retraction).

Dan

[Sebastien Binet]

Hi Jay,

On Thu Jul 1, 2021 at 00:45 CET, Jay Conrod wrote:
> Hi Sebastien, once a version is in proxy.golang.org, it usually can't be
> removed. This is important to ensure that builds continue working when a
> repository disappears upstream.
>
> You may want to publish a new version with a retract directive in
> go.mod,
> marking the earlier versions as invalid. In Go 1.16 and higher, the go
> command won't automatically upgrade to a retracted version. The version
> containing the retractions may retract itself. Retract Module Versions

> <https://play-with-go.dev/retract-module-versions_go116_en/> is an

> interactive tutorial explaining how to use this feature.
>
> Even with retractions in place, you won't be able to reuse the old
> version
> numbers. They'll be hidden, but still available to any users that depend
> on
> them.

thanks for the pointer to the tutorial.
I think I did apply all the expected operations on my repo:

- tagged a v0.4.1 version with the `retract v1.4.2` stanza:
https://github.com/go-pdf/fpdf/pull/10/files#diff-33ef32bf6c23acb95f5902d7097b7a1d5128ca061167ec0716715b0b9eeaa5f6
- waited for a minute or so and issued:

$> go list -versions -m
github.com/go-pdf/fpdf v0.1.0 v0.2.0 v0.3.0 v0.3.1 v0.4.0 v0.4.1 v1.4.2

I also requested v0.4.1 both on the pkg.go.dev site and explicitly in a
dummy module with `go get github.com/go-pdf/fp...@v0.4.1`:

$> mkdir foo && cd ./foo
$> go mod init foo
$> go get -u -v github.com/go-pdf/fp...@v0.4.1
github.com/go-pdf/fpdf

$> go get -u -v github.com/go-pdf/fpdf
go get: github.com/go-pdf/fp...@v1.4.2: parsing go.mod:

module declares its path as: github.com/phpdave11/gofpdf
but was required as: github.com/go-pdf/fpdf

I am probably handing it the wrong way.
(I am using go-tip at 9d65578b83)

thanks again,
-s

[Jay Conrod]

As Dan mentioned, the version containing the retractions must be the highest version, so you'd need to tag v1.4.3 or higher. If that version retracts itself, it won't appear in the version list either.

[Sebastien Binet]

On Thu Jul 1, 2021 at 17:47 CET, Jay Conrod wrote:
> As Dan mentioned, the version containing the retractions must be the
> highest version, so you'd need to tag v1.4.3 or higher. If that version
> retracts itself, it won't appear in the version list either.

right.

indeed, after having tagged v1.4.3 with:

retract (
// v1.4.3 was tagged to retract v1.4.2
v1.4.3
// v1.4.2 was imported from phpdave11/gofpdf by mistake.
v1.4.2
)

everything worked as it should.

thanks a lot for the help.

-s