Errors you may encounter when upgrading these dependencies

[KateGo520]

(The purpose of this report is to alert cockroachdb/cockroach to the possible problems when cockroachdb/cockroach try to upgrade the following dependencies)

An error will happen when upgrading libraries jackc/pgx, cockroachdb/apd and _spf13/cobra _:

github.com/jackc/pgx

-Version: v4.6.0 (Latest commit 0446492 on 31 Mar)
-Where did you use it:
https://github.com/cockroachdb/cockroach/search?q=jackc%2Fpgx&unscoped_q=jackc%2Fpgx
-Detail:

github.com/jackc/pgx/go.mod

module github.com/jackc/pgx/v4
go 1.12
require (
	github.com/jackc/pgproto3/v2 v2.0.1
	github.com/jackc/pgtype v1.3.0
	…
)

github.com/jackc/pgx/conn.go

package pgx

import (
	"github.com/jackc/pgproto3/v2"
	"github.com/jackc/pgtype"
	"github.com/jackc/pgx/v4/internal/sanitize"
	…
)

This problem was introduced since jackc/pgx v4.0.0 .Now you used version v3.6.2. If you try to upgrade jackc/pgx to version v4.0.0 and above, you will get an error--- no package exists at "github.com/jackc/pgx/v4" and "github.com/jackc/pgproto3/v2"

Similar issues can also happen when upgrading libraries github.com/spf13/cobra, cockroachdb/apd.

I investigated the libraries' (spf13/cobra, cockroachdb/apd and coreos/go-systemd) release information and found the root cause of this issue is that----

1. These dependencies all added Go modules in the recent versions.

2. They all comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation. Quoting the specification:

A package that has migrated to Go Modules must include the major version in the import path to reference any v2+ modules. For example, Repo github.com/my/module migrated to Modules on version v3.x.y. Then this repo should declare its module path with MAJOR version suffix "/v3" (e.g., module github.com/my/module/v3), and its downstream project should use "github.com/my/module/v3/mypkg" to import this repo’s package.

3. This "github.com/my/module/v3/mypkg" is not the physical path. So Go versions older than 1.9.7 and 1.10.3 plus all third-party dependency management tools (like dep, glide, govendor, etc) don't have minimal module awareness as of now and therefore don't handle import paths correctly.

Note: creating a new branch is not required. If instead you have been previously releasing on master and would prefer to tag v3.0.0 on master, that is a viable option. (However, be aware that introducing an incompatible API change in master can cause issues for non-modules users who issue a go get -u given the go tool is not aware of semver prior to Go 1.11 or when module mode is not enabled in Go 1.11+).
Pre-existing dependency management solutions such as dep currently can have problems consuming a v2+ module created in this way. See for example dep#1962.
https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

Solution

1. Migrate to Go Modules.

Go Modules is the general trend of ecosystem, if you want a better upgrade package experience, migrating to Go Modules is a good choice.

Migrate to modules will be accompanied by the introduction of virtual paths(It was discussed above).

This "github.com/my/module/v3/mypkg" is not the physical path. So Go versions older than 1.9.7 and 1.10.3 plus all third-party dependency management tools (like dep, glide, govendor, etc) don't have minimal module awareness as of now and therefore don't handle import paths correctly.

Then the downstream projects might be negatively affected in their building if they are module-unaware (Go versions older than 1.9.7 and 1.10.3; Or use third-party dependency management tools, such as: Dep, glide, govendor…).

[*] You can see who will be affected here: [22 module-unaware users, i.e., akraino-edge-stack/iec-xconnect, tinyzimmer/vault-plugin-java-pki, andydodo/prometheus]
https://github.com/search?q=cockroachdb%2Fcockroach+filename%3Avendor.conf+filename%3Avendor.json+filename%3Aglide.toml+filename%3AGodep.toml+filename%3AGodep.json&type=Code

2. Maintaining v2+ libraries that use Go Modules in Vendor directories.

If cockroachdb/cockroach want to keep using the dependency manage tools (like dep, glide, govendor, etc), and still want to upgrade the dependencies, can choose this fix strategy.
Manually download the dependencies into the vendor directory and do compatibility dispose(materialize the virtual path or delete the virtual part of the path). Avoid fetching the dependencies by virtual import paths. This may add some maintenance overhead compared to using modules.

There are 191 module users downstream, such as KinyaElGrande/GoGraphql, cockroachdb/cockroach-gen, cockroachdb/cockroach…)
https://github.com/search?q=cockroachdb%2Fcockroach+filename%3Ago.mod&type=Code
As the import paths have different meanings between the projects adopting module repos and the non-module repos, materialize the virtual path is a better way to solve the issue, while ensuring compatibility with downstream module users. A textbook example provided by repo github.com/moby/moby is here:
https://github.com/moby/moby/blob/master/VENDORING.md
https://github.com/moby/moby/blob/master/vendor.conf
In the vendor directory, github.com/moby/moby adds the /vN subdirectory in the corresponding dependencies.
This will help more downstream module users to work well with your package, otherwise they will be stuck in github.com/jackc/pgx v3.6.2 .

3. Request upstream to do compatibility processing.

The jackc/pgx have 27 module-unaware users in github, such as: czendee/bancotizador, czendee/IGS_tokenization, jiinwoojin/tegola…
https://github.com/search?o=desc&q=jackc%2Fpgx+filename%3Avendor.conf+filename%3Avendor.json+filename%3Aglide.toml+filename%3AGodep.toml+filename%3AGodep.json&s=indexed&type=Code

Summary

You can make a choice when you meet this DM issues by balancing your own development schedules/mode against the affects on the downstream projects.

For this issue, Solution 1 can maximize your benefits and with minimal impacts to your downstream projects the ecosystem.

References

• https://github.com/golang/go/wiki/Modules#semantic-import-versioning
• https://golang.org/cmd/go/#hdr-Module_compatibility_and_semantic_versioning
• https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

Do you plan to upgrade the libraries in near future?
Hope this issue report can help you ^_^
Thank you very much for your attention.

Best regards,
Kate

[blathers-crl]

Hello, I am Blathers. I am here to help you get the issue triaged.

It looks like you have not filled out the issue in the format of any of our templates. To best assist you, we advise you to use one of these templates.

I have CC'd a few people who may be able to assist you:

• @petermattis (commented on sql: any plan of implementing 'UPSERT' or 'ON DUPLICATE KEY UPDATE' ? #1962)
• @rafiss (found keywords: pgx)
• @cockroachdb/bulk-io (found keywords: import)
• @danhhz (assigned to sql: any plan of implementing 'UPSERT' or 'ON DUPLICATE KEY UPDATE' ? #1962)

If we have not gotten back to your issue within a few business days, you can try the following:

• Join our community slack channel and ask on #cockroachdb.
• Try find someone from here if you know they worked closely on the area and CC them.

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is otan.}

[otan]

we've been trying :) #49447
coming soon, hopefully.

[KateGo520]

@otan Thank you for your contribution!