Module should be github.com/cheat/cheat/v4 for Go's indexing servers to pick it up

[yurivict]

No description provided.

[jeffwidman]

I have a main.go file whose sole purpose is to have a dummy import like:

// This import isn't buildable because it's not an importable package, but
// it is `go mod tidy`-able, which is all we need.
_ "github.com/cheat/cheat/cmd/cheat"

so that I can run go mod tidy against that file in order to pin the version of cheat in such a way that Dependabot can watch for new versions and open PR's notifying me... that way I don't have to check for new versions, but I also get reproducible builds.

So I was surprised to see that go mod tidy pulled in

require github.com/cheat/cheat v0.0.0-20211009161301-12ffa4cb5c87

When I manually changed to require github.com/cheat/cheat v4.2.3, I got the failure:

$ go mod tidy -compat=1.17
go: errors parsing go.mod:
/.../cheat/go.mod:5: require github.com/cheat/cheat: version "v4.2.3" invalid: should be v0 or v1, not v4

So please update the module path to match the v4 version to be compatible with the go mod tidy machinery.

[chrisallenlane]

I'm sorry, but I'm going to have to ask some dumb questions here, because I haven't kept up with the Go ecosystem as closely as I should have:

1. What are the "Go indexing servers?" (Googling this has not proved fruitful).
2. @jeffwidman, what version of Go are you running? I ask because go mod tidy is a regular part of my workflow, and it at least appears to work fine.

in such a way that Dependabot can watch for new versions and open PR's notifying me.

I've been surprised that Dependabot hasn't opened any PRs against cheat for a while, so I'm sure you're right. I'm just unclear on some of the details here. Any relevant information you could share to bring me up to speed would be greatly appreciated.

[yurivict]

What are the "Go indexing servers?" (Googling this has not proved fruitful).

Google has servers that list all Golang packages such that this script can list them:

$ cat go-retrieve-all-packages.sh
#!/bin/sh

SINCE=$1 # like 2022-07-01T00:00:00Z

while [ -n "${SINCE}" ]; do

	# download
	echo "downloading SINCE=${SINCE}"
	wget "https://index.golang.org/index?limit=2000&since=${SINCE}" -q -O output-${SINCE}.json

	# get last since
	SINCE_NEW=`tail -1 output-${SINCE}.json | sed -e 's|.*"Timestamp":"||; s|".*||'`

	# EOF?
	if [ "${SINCE_NEW}" = "${SINCE}" ] || [ -z "${SINCE_NEW}" ]; then
		echo "=== End of project list reached @ ${SINCE} ==="
		exit 0
	else
		SINCE=${SINCE_NEW}
	fi
done

Golang requires that module name should be github.com/{acct}/{project}/v{major-version} in order to be listed.

[yurivict]

Any chance to resolve this?

[chrisallenlane]

@yurivict, I spent some time looking at this again last week, and I'm still unclear what the problem is, and what I'm supposed to do to solve it. I'm also not clear what interest I'm supposed to have in Google's indexing servers.

From what I read, Google wants tags in the format of v1.2.3 instead of 1.2.3, but I'm reluctant to break the convention that this project has been using for years for benefits that I can't understand.

Perhaps I'm dense. If you'd like to elaborate a bit more on what the problem is, what the solution is, and what the benefit is, I'd appreciate it.

[yurivict]

qbrush is installed by QtGui (either from Qt5 or Qt6):

[yuri@yv /usr/ports/audio/seq66]$ pkg which /usr/local/include/qt5/QtGui/qbrush.h
/usr/local/include/qt5/QtGui/qbrush.h was installed by package qt5-gui-5.15.11p135
[yuri@yv /usr/ports/audio/seq66]$ pkg which /usr/local/include/qt6/QtGui/qbrush.h
/usr/local/include/qt6/QtGui/qbrush.h was installed by package qt6-base-6.6.1

[chrisallenlane]

@ yurivict, did you reply to the wrong thread with the above?

[yurivict]

Yes, wrong thread, sorry about this.

[yurivict]

The package documentation site pkg.go.dev and the Go module proxy (used by go get, go install etc.) use the Golang index server to discover new modules, see big picture (godoc.org is now replaced by pkg.go.dev).

[jeffwidman]

Sorry @chrisallenlane I'd forgotten to circle back on this... I think all you need to do is update the published module path:

• Change module path to v4 per go conventions #750

Downstream users will need to update their imports, but that's not something you control... Here's an example of importing another package that has a major version > 1:
https://github.com/alecthomas/chroma/blob/9347b550abb84248f8421e842ec50fb488cdbb57/go.mod#L6

This install instruction may need to be modified to include the v4 as well, but I don't remember for sure... :

cheat/INSTALLING.md

Line 32 in 7908a67

go install github.com/cheat/cheat/cmd/cheat@latest

Easiest to test after you merge this and give it a moment for the Go indexing server to pick it up and then see what go install says... and if it's installing the v4 variant or not.

As far as whether the v prefix is required in your release versions, I don't remember for sure... it's been a few years since I worked professionally in go and knew all this off the top of my head. 😀