Option to disable version validation in 1.13?

[Steven Hartland]

Trying to update to 1.13 but the new version validation breaks
golangci-lint installs with:
invalid pseudo-version: does not match version-control timestamp

https://golang.org/doc/go1.13#version-validation lists a number of
options if you're maintaining a module but nothing seems relevant for
CI/CD pipelines which are just trying to use tools for which they aren't
the maintainer.

On my local box I ended up downgrading to go 1.12.9 running the install,
which downloaded the dependencies into the cash then upgrading again and
reinstalling to get go 1.13 compiled versions of golangci-lint.

GO111MODULE=on go get
github.com/golangci/golangci-lint/cmd/golang...@v1.17.1

The standard way to install golangci-lint from binaries fails due to
what seems like conflicts with the changes in go 1.13, erroring out in
various linters.

So the question is:
* Is there option to disable this behaviour so we don't have to get
every single tools dependencies fixed to pass this new validation just
to use them?

    Regards
    Steve

[t hepudds]

Hello Steve,

> https://golang.org/doc/go1.13#version-validation lists a number of 

> options if you're maintaining a module but nothing seems relevant for 

> CI/CD pipelines which are just trying to use tools for which they aren't 

> the maintainer. 

Regarding how to fix "invalid pseudo-version" errors, I think the release notes are also trying to give options for someone trying to use tools for which they aren't the maintainer (as well as options for maintainers).

The paragraph on the `replace` directive in that section of the release notes I think is something you can use, even if you are not the maintainer of a module with an invalid version. In general, the `replace` directive basically gives your module complete control over its own build in terms of what versions to use.

More specifically, using Go 1.13, this fails with an "invalid pseudo-version" error (as expected):

   export GOPATH=$(mktemp -d)               # using fresh module cache

   cd $(mktemp -d)                   

   go mod init example.com/tempmod     

   go get github.com/golangci/golangci-lint/cmd/golang...@v1.17.1 

which reports error:

  go: extracting github.com/golangci/golangci-lint v1.17.1

  go get: github.com/golangci/golang...@v1.17.1 requires

        github.com/go-critic/go-c...@v0.0.0-20181204210945-1df300866540: invalid pseudo-version: does not match version-control timestamp (2019-05-26T07:48:19Z)

It looks like there has been some discussion of solving this within golangci, including here and some related issues there:

  

   https://github.com/golangci/golangci-lint/pull/605

  

It looks like some of the core Go team has commented there with advice, but looks like it is still pending changes there.

   

However, we don't need to wait for that to be resolved within golangci.

If we follow the advice from the section of the Go 1.13 release notes on resolving version validation issues ( valhttps://golang.org/doc/go1.13#version-validation), we can make that same 'go get' work:

   # re-do setup from scratch

   export GOPATH=$(mktemp -d)               # using fresh module cache

   cd $(mktemp -d)                   

   go mod init example.com/tempmod

   # create 'replace' statements using *just* the commit hashes for each problematic module on the right-hand side

   echo 'replace github.com/go-critic/go-critic v0.0.0-20181204210945-1df300866540 => github.com/go-critic/go-critic 1df300866540' >> go.mod

   echo 'replace github.com/golangci/errcheck v0.0.0-20181003203344-ef45e06d44b6 => github.com/golangci/errcheck ef45e06d44b6' >> go.mod

   echo 'replace github.com/golangci/go-tools v0.0.0-20180109140146-af6baa5dc196 => github.com/golangci/go-tools af6baa5dc196' >> go.mod

   echo 'replace github.com/golangci/gofmt v0.0.0-20181105071733-0b8337e80d98 => github.com/golangci/gofmt 0b8337e80d98' >> go.mod

   echo 'replace github.com/golangci/gosec v0.0.0-20180901114220-66fb7fc33547 => github.com/golangci/gosec 66fb7fc33547' >> go.mod

   echo 'replace github.com/golangci/ineffassign v0.0.0-20180808204949-42439a7714cc => github.com/golangci/ineffassign 42439a7714cc' >> go.mod

   echo 'replace github.com/golangci/lint-1 v0.0.0-20180610141402-ee948d087217 => github.com/golangci/lint-1 ee948d087217' >> go.mod

   echo 'replace mvdan.cc/unparam v0.0.0-20190124213536-fbb59629db34 => mvdan.cc/unparam fbb59629db34' >> go.mod

   # this now works

   go get github.com/golangci/golangci-lint/cmd/golang...@v1.17.1 

Regards,

thepudds

[Steven Hartland]

Yer replace is mentioned in the link I provided too and I’d seen that thread, but as you can see from the amount of effort required I would suggest that it’s currently not practical to have everyone go through that process; particularly for tools when they just want to install and use not develop against it.

In our company we’ve tried several times now to migrate to go mods and each time we’ve given up as third party libs are simply not ready, this is just another example of that.

I totally agree with the why but the practicalities should not be ignored and hence there should be way to easily disable this check while libs and tools address the issues; similarly to how checksums can be disabled.

In our case were now using a patched 1.13 with this check removed as that was by far the path of least resistance, which is something we really don’t want to do.

   Regards

   Steve

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/61026e02-528c-474f-bc0f-8c8b8da815d6%40googlegroups.com.