Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

go.mod does not specify v2 version #663

Closed
hvastani opened this issue Apr 2, 2019 · 14 comments
Closed

go.mod does not specify v2 version #663

hvastani opened this issue Apr 2, 2019 · 14 comments

Comments

@hvastani
Copy link

hvastani commented Apr 2, 2019

The go.mod file in this repo does not specify the /v2 tag so if this module is imported in any project, it will be imported with +incompatible
From the official documentation (https://github.com/golang/go/wiki/Modules)

The module path (such as module foo/v2) declared at the start of a module's go.mod file is both:
the definitive declaration of that module's identity
the definitive declaration of how that module must be imported by consuming code

A module can import a v2+ package that has not opted in to modules itself. A non-module v2+ package that has a valid v2+ semver tag will be recorded with an +incompatible suffix in the importing module's go.mod file. The +incompatible suffix indicates that even though the v2+ package has a valid v2+ semver tag such as v2.0.0, the v2+ package has not actively opted in to modules and hence that v2+ package is assumed to have not been created with an understanding of the implications of Semantic Import Versioning and how to use major versions in import paths. Therefore, when operating in module mode, the go tool will treat a non-module v2+ package as an (incompatible) extension of the v1 version series of the package and assume the package has no awareness of Semantic Import Versioning, and the +incompatible suffix is an indication that the go tool is doing so.

Tested this on centos linux and saw this in my go.mod file
github.com/shirou/gopsutil v2.18.12+incompatible
When I tested this, the current tag was 2.19.03
My go version
go version go1.11 linux/amd64

@Lomanic
Copy link
Collaborator

Lomanic commented Apr 3, 2019

Looks like we would need a /v2 in the import path for it to be not flagged as incompatible (github.com/shirou/gopsutil/v2/...), using a v2 branch it seems according to https://research.swtch.com/vgo-module#from_repository_to_modules

@shirou
Copy link
Owner

shirou commented Apr 12, 2019

I am not familiar with mod yet, but I think go module can adapt git tag and gopsutil already has version aware git tags. And I don't want to version package directory like gopsutil/v2/disk/disk_linux.go

@ppmathis
Copy link

ppmathis commented Jun 29, 2019

Please note that aside of breaking Go module standards as mentioned earlier in this issue, this repository also actively breaks the semantic versioning standard due to the patch version containing leading zeroes:

Quote from SemVer paragraph 2: A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

This leads to the side effect of go get -u github.com/shirou/gopsutil pulling in v2.18.12 instead of v2.19.05, as it is the newest SemVer-compatible version tag. The newest version of gopsutil has to be pulled using go get github.com/shirou/gopsutil@2.19.05, which will end up as a pseudo-version in go.mod: v0.0.0-20190601025009-5335e3fd506d

Aside from highly advising you to actually pay attention to the Go modules specification and fixing the incorrect import path, I would at least either re-release the current version tag as v2.19.5 or create a new release as v2.19.6 to ensure users are working with the latest release.

@shirou
Copy link
Owner

shirou commented Jun 29, 2019

I'm not sure why the go mod thinks v.2.18.12 is newer than v2.19.05. Those are SemVer.

@ppmathis
Copy link

I'm not sure why the go mod thinks v.2.18.12 is newer than v2.19.05. Those are SemVer.

Please re-read the paragraph I have quoted from the SemVer specifications page, which states [...] are non-negative integers, and MUST NOT contain leading zeroes. [...]. Your currently used version number is violating the SemVer specification as the patch version, which is 5, is being written with a leading zero as 05.

@shirou
Copy link
Owner

shirou commented Jun 30, 2019

ah, ok, understood.

So, I tagged v2.19.6 now. Thank you for your comment!

@shirou shirou closed this as completed Jun 30, 2019
@calvn
Copy link

calvn commented Aug 15, 2019

It seems that despite removing the leading zero, go mod still pulls it using the pseudo-version:

› go get github.com/shirou/gopsutil@v2.19.7
go: finding github.com/shirou/gopsutil v2.19.7
go: downloading github.com/shirou/gopsutil v0.0.0-20190731134726-d80c43f9c984
go: extracting github.com/shirou/gopsutil v0.0.0-20190731134726-d80c43f9c984

Pulling latest also pins it to v2.18.12 despite having newer releases that are SemVer compatible:

› go get github.com/shirou/gopsutil@latest 

go.mod:

	...
	github.com/shirou/gopsutil v2.18.12+incompatible // indirect
	...

@Xuanwo
Copy link

Xuanwo commented Sep 20, 2019

@shirou @calvn

Because there is no v2 in the import path but the tag is v2.19.7, so go mod will use pseudo-version to mark it's a incompatible mod: treat v2.19.7 as a simple string instead of a semver tag.

And pull from latest will get v2.18.12 because v2.18.12 is the last version before adapting go module, the last valid version with import path github.com/shirou/gopsutil

So, there are two options here:

  • Do not provide a go.mod file, go will always treat this repo in /v1 but with a high tag.
  • Add /v2 into the path to meet go module requirement.

@shirou
Copy link
Owner

shirou commented Sep 20, 2019

I really don't want to add /v2 path. So just remove go.mod file?

@Lomanic
Copy link
Collaborator

Lomanic commented Sep 20, 2019

Adding a v2 branch might do it, or maybe even default branch could be v2 instead of master (see my first comment and link). But if it means people then would have to import "github.com/shirou/gopsutil/v2/process" I'm also not fond of this. Removing the go.mod is simpler.

jirfag pushed a commit to golangci/golangci-lint that referenced this issue Sep 20, 2019
Note, dependency has to be pinned to a specific release version
commit hashes since it doesn't follow Go module v2+ guidelines.

see:
shirou/gopsutil#663
golang/go#34402
@shirou
Copy link
Owner

shirou commented Sep 22, 2019

I did those combinations

  1. remove go.mod
  2. changed go.mod to add v2 in module module github.com/shirou/gopsutil -> module github.com/shirou/gopsutil/v2
  3. we still have 0 padding git branch like v2.19.05 in repository. so rename those.

on my local pc. but still have incompatible or occurd this error

go: finding github.com/shirou/gopsutil/v2 v2.19.8
build github.com/shirou/test: cannot load github.com/shirou/gopsutil/v2/process: module github.com/shirou/gopsutil@latest (v2.18.12+incompatible) found, but does not contain package github.com/shirou/gopsutil/v2/process

I have tested on just my local pc, so it might be not affected, but those seem no luck.

@shirou
Copy link
Owner

shirou commented Sep 22, 2019

I am using go version go1.13 linux/amd64. Possibly, it time to start v3 ???

@Xuanwo
Copy link

Xuanwo commented Sep 23, 2019

v2 should be added to every import of github.com/shirou/gopsutil.

github.com/shirou/gopsutil/v2 and github.com/shirou/gopsutil are different import path for go modules.

dragetd added a commit to setlog/trivrost that referenced this issue Apr 3, 2020
The author has issues wrapping this into a correct module. See
shirou/gopsutil#663
dragetd added a commit to setlog/trivrost that referenced this issue Apr 3, 2020
The author has issues wrapping this into a correct module. See
shirou/gopsutil#663
@shirou
Copy link
Owner

shirou commented Nov 1, 2020

Sorry for the very long time wait. I have released v3 by #938 which has go.mod.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants