Go-tools: Add go.mod

[ainar-g]

Go 1.11 is out. Is it time to add a Go module definition? It shouldn't break Go 1.10 and below, but will add an option to work on the project without a GOPATH.

[dominikh]

Not yet. I'd first like to see where modules are going and what workflows emerge.

Plus, strictly speaking, we cannot abide by the modules requirements. This project very much doesn't use semantic versioning, and I'm not planning on changing that; every release of staticcheck is potentially breaking backwards compatibility, as far as its APIs are concerned. Having to change import paths for that would be quite the nuisance.

[ainar-g]

Does anyone actually import the packages from the repo? Have you considered moving them into internal/? My projects at $COMPANY_NAME are basically all binary-driven, and so they are nothing but internal/.

[dominikh]

I know some people who implement their own tools using my framework (being fully aware of their unstable nature.)

[dmitshur]

Plus, strictly speaking, we cannot abide by the modules requirements. This project very much doesn't use semantic versioning, and I'm not planning on changing that; every release of staticcheck is potentially breaking backwards compatibility, as far as its APIs are concerned.

Adding a go.mod file doesn't necessarily mean you have to start using semantic versioning at the same time. That can happen later (if ever). Until then, you'd be relying on pseudo-verisions that naturally happen from each commit. Since they'd be v0.0.0-..., v0 is allowed to make breaking API changes.

See the golang.org/x subrepos as an example of that. Other than golang.org/x/text which had a few semantic tags added before modules, all others are relying on pseudo-versions only. For example, see https://github.com/golang/time/commit/9d24e82272b4f38b78bc8cff74fa936d31ccd8ef and also see https://github.com/golang/go/issues/28136#issuecomment-462971974 that describes the current strategy.

To explain the motivation for my 👍 to this repository getting a go.mod file: I want to be able to more easily compute the vanity import path from the git remote URL. Without a go.mod file, that can be done by looking through packages and finding their import comments (like this one), but that's more computationally expensive to do.

So for my needs, just a single line module honnef.co/go/tools go.mod file would be sufficient; I don't have a need for specific module version requirements to be specified in it.

[dmitshur]

I want to be able to more easily compute the vanity import path from the git remote URL.

And the reason I want that is so that I can show this on my personal website:

Instead of the current:

🙂

[dominikh]

The modules branch contains WIP commits that add a go.mod file, as well as code that makes use of module information embedded in the binary. You can download it in module mode via go get honnef.co/go/tools/cmd/staticcheck@modules.

We will continue to use our own versioning scheme that isn't semver. This means that go get [email protected] will work, but store a pseudo-version in the go.mod. I think that is acceptable.

The plan is to merge modules into incr and incr into master soon, hopefully in June. At that point, the master branch will be a proper Go module.

If you'd like to, go get from the modules branch and see if everything works as expected. In particular, give staticcheck -version and staticcheck -debug.version a go. The former should now include the pseudo version in its output, and the latter should display detailed information about the main module as well as its dependencies.

Edit: The modules branch has since been merged into incr.

[dominikh]

Closed in ced03d0

[dmitshur]

I'm happy to say that what I described in https://github.com/dominikh/go-tools/issues/346#issuecomment-473555245 above has been implemented (in commit https://github.com/shurcooL/events/commit/5bd98dd6544e32f15023245a6225fdbbe4cc9ceb). For example:

So thanks for adding the go.mod file that made this possible!