Prysm import paths should include a virtual v2 version for go.mod semver support

[kasey]

💎 Issue

In order for users to specify prysm as a dependency in go.mod, using a version tag >= v2.0.0, we need to update our packages to correctly implement the go module system's special requirements for 2.0+ packages. This entails a change to go.mod and a sweeping rewrite of existing import paths. Until we've made this change, any consumer of prysm packages > 2.0.0 will need to pin prysm with a pseudo version specifying a specific commit hash, eg require github.com/prysmaticlabs/prysm v0.0.0-20211018163532-a80b1c252a9b.

Background & Description

A quirk of go modules using semantic versioning is that v1 is a special implicit version, but once you increment to v2 and beyond, you need to append v2 to the package path declared in go.mod. Go does this to ensure that a version of a package with a breaking change has a different import path. In our case, the module github.com/prysmaticlabs/prysm directive in go.mod needs to be updated to module github.com/prysmaticlabs/prysm/v2. Otherwise, any 3rd party trying to use our github tags like 2.0.4 will mistakenly get the newest 1.x tag.

The implication of that change is that every package import path within prysm itself will need to be rewritten. For instance:

import "github.com/prysmaticlabs/prysm/config/params"

needs to be rewritten as:

import "github.com/prysmaticlabs/prysm/v2/config/params"

This was previously done with a sed one-liner in the branch v2 for testing purposes here: f5956d3
Note that we also need to update the proto annotation for the go import path: 596b3ac

Official go doc about moving packages to v2 and beyond:
https://go.dev/blog/v2-go-modules

[prestonvanloon]

Kind of related: #10046

[alrevuelta]

Great! Looking forward :)

Our of curiosity, do you know why v2.0.1 is listed here? Why that version and not any other?

$ go list -m -versions "github.com/prysmaticlabs/prysm/v2"
github.com/prysmaticlabs/prysm/v2 v2.0.1

[zx8]

Also interested in this!

Without the /v2 suffix, it makes working with prysm as a dependency in go.mod really painful...

[abdulrabbani00]

@prestonvanloon - Has there been any progress on this, I would love to use the latest version of the code in my repo.

[rkapka]

Hi @abdulrabbani00 , the merge presents a great opportunity to release Prysm v3. We will most likely include this "feature" there, but not for v2.

[abdulrabbani00]

@rkapka - Okay, so does that mean we will have to wait until the merge happens or do you plan on have v3 released significantly prior to the merge?

[offerm]

Hi @rkapka why adding /v2 to the module line in go.mod is a "feature"?

This should allow

github.com/prysmaticlabs/prysm v2.1.3

instead of

github.com/prysmaticlabs/prysm v1.4.2-0.20220630150133-69350a6a808a

What is the downside in doing this?

[nyetwurk]

github.com/prysmaticlabs/prysm v2.1.3

golang does not allow this in a require

go.mod:7: require github.com/prysmaticlabs/prysm: version "v2.1.3" invalid: should be v0 or v1, not v2

[nyetwurk]

why was this closed?

go: finding module for package github.com/grpc-ecosystem/grpc-gateway/v2/proto/gateway
go: finding module for package github.com/prysmaticlabs/prysm/proto/prysm/v1alpha1
go.blockdaemon.com/collectors/eth2-collector/pkg/eth imports
	github.com/prysmaticlabs/prysm/proto/prysm/v1alpha1: module github.com/prysmaticlabs/prysm@latest found (v1.4.4), but does not contain package github.com/prysmaticlabs/prysm/proto/prysm/v1alpha1
go.blockdaemon.com/collectors/eth2-collector/pkg/eth imports
	github.com/prysmaticlabs/prysm/proto/eth/v1 imports
	github.com/grpc-ecosystem/grpc-gateway/v2/proto/gateway: module github.com/grpc-ecosystem/grpc-gateway/v2@latest found (v2.14.0), but does not contain package github.com/grpc-ecosystem/grpc-gateway/v2/proto/gateway

[nisdas]

@nyetwurk Prysm is currently in v3 , we fixed this in our v3 release to align with go.mod semver support. If you change the prysm version to v3 , you shouldn't have any issues

[nyetwurk]

Our current includes look like

        ethv1 "github.com/prysmaticlabs/prysm/proto/eth/v1"
        ethv1alpha1 "github.com/prysmaticlabs/prysm/proto/prysm/v1alpha1"

How should they look in v3?

[nyetwurk]

Specifically

// GetVersion returns the version string of the running beacon node.
func (c *Client) GetVersion(ctx context.Context) (res *ethv1.Version, err error) {
	version, err := c.getVersionV1(ctx)
	if err == nil {
		return version.GetData(), nil
	}
	// Some nodes don't support the v1 endpoint yet. Fall back to v1alpha1.
	alphaVersion, err2 := c.getVersionV1Alpha1(ctx)
	if err2 != nil {
		return nil, fmt.Errorf("both version endpoints failed. err1: %s; err2: %s", err, err2)
	}
	res = &ethv1.Version{Version: alphaVersion.GetVersion()}
	return res, nil
}

func (c *Client) getVersionV1Alpha1(ctx context.Context) (res *ethv1alpha1.Version, err error) {
	res = new(ethv1alpha1.Version)
	err = c.Get(ctx, res, "/eth/v1alpha1/node/version")
	return
}

func (c *Client) getVersionV1(ctx context.Context) (res *ethv1.VersionResponse, err error) {
	res = new(ethv1.VersionResponse)
	err = c.Get(ctx, res, "/eth/v1/node/version")
	return
}

presumably something like

	ethv1 "github.com/prysmaticlabs/prysm/v3/proto/eth/v1"
	ethv1alpha1 "github.com/prysmaticlabs/prysm/v3/proto/prysm/v1alpha1"

[nisdas]

@nyetwurk That is correct, using the above format for v3 should work. Let us know if that is not the case.