Skip to content

Cannot go get due to invalid pseudo-version #730

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

Closed
howardjohn opened this issue Sep 23, 2019 · 9 comments
Closed

Cannot go get due to invalid pseudo-version #730

howardjohn opened this issue Sep 23, 2019 · 9 comments
Assignees
Labels
bug Something isn't working

Comments

@howardjohn
Copy link

I tried to run go get to grab the latest master but running into some issues

$ go get github.com/golangci/golangci-lint/cmd/golangci-lint@master
go: finding github.com/golangci/golangci-lint master
go: finding github.com master
go: finding github.com/golangci/golangci-lint/cmd master
go: finding github.com/golangci master
go: finding github.com/golangci/golangci-lint/cmd/golangci-lint master
go get: github.com/golangci/[email protected] requires
        github.com/goreleaser/[email protected] requires
        code.gitea.io/[email protected] requires
        github.com/go-macaron/[email protected]: invalid pseudo-version: revision is longer than canonical (6fd6a9bfe14e)

What is really weird is if I clone the repo and do go install ./cmd/golangci-lint it works perfectly fine.

Maybe I am just doing something wrong, since it looks like there is a replace in go.mod to fix this, but somehow not getting applied on go get

$ go version
go version go1.13 linux/amd64
@zikaeroh
Copy link

See also: goreleaser/goreleaser#1145

@jirfag
Copy link
Contributor

jirfag commented Sep 23, 2019

/cc @tpounds

@tpounds
Copy link
Contributor

tpounds commented Sep 23, 2019

@howardjohn Thanks for reporting. Issue is caused by broken deps in upstream goreleaser tools. A couple of issues/pull requests have been open to fix this.

goreleaser/goreleaser#1145
goreleaser/goreleaser#1152
goreleaser/godownloader#133

We should be able to fix this ASAP once the upstream issues are resolved. In the meantime, a quick and dirty hack is to pin deps using replace in your project go.mod file (e.g. https://github.com/golangci/golangci-lint/blob/master/go.mod#L52).

@tpounds
Copy link
Contributor

tpounds commented Sep 24, 2019

So...I attempted a fix with a few upstream patches, however, the github.com/go-macaron/[email protected]: invalid pseudo-version still persists. I've narrowed this down to a format discrepancy between setting GOPROXY to gocenter.io which is used by goreleaser and more permissive than the default proxy.golang.org. Unfortunately, an upstream fix is going to be a bit more involved to unwind the broken transitive dependency. To unblock downstream projects I think it will be best to create a separate tools/go.mod file to manage the project deps.

@pierrre
Copy link
Contributor

pierrre commented Sep 24, 2019

Same issue when I try to install from vscode:

Installing 1 tool at /home/pierre/go/bin
  golangci-lint

Installing github.com/golangci/golangci-lint/cmd/golangci-lint FAILED

1 tools failed to install.

golangci-lint:
Error: Command failed: /home/pierre/.gimme/versions/go1.13.src/bin/go get -v github.com/golangci/golangci-lint/cmd/golangci-lint
go get: github.com/golangci/[email protected] requires
	github.com/goreleaser/[email protected] requires
	code.gitea.io/[email protected] requires
	github.com/go-macaron/[email protected]: invalid pseudo-version: revision is longer than canonical (6fd6a9bfe14e)
go get: github.com/golangci/[email protected] requires
	github.com/goreleaser/[email protected] requires
	code.gitea.io/[email protected] requires
	github.com/go-macaron/[email protected]: invalid pseudo-version: revision is longer than canonical (6fd6a9bfe14e)

@pierrre
Copy link
Contributor

pierrre commented Sep 24, 2019

It's also broken in v1.19.0 (not only master):

➜  ~ GO111MODULE=on go get -v github.com/golangci/golangci-lint/cmd/[email protected] 
go: finding github.com v1.19.0
go: finding github.com/golangci v1.19.0
go: finding github.com/golangci/golangci-lint/cmd v1.19.0
go: finding github.com/golangci/golangci-lint/cmd/golangci-lint v1.19.0
go get: github.com/golangci/[email protected] requires
	github.com/goreleaser/[email protected] requires
	code.gitea.io/[email protected] requires
	github.com/go-macaron/[email protected]: invalid pseudo-version: revision is longer than canonical (6fd6a9bfe14e)

fsouza added a commit to fsouza/go-dockerclient that referenced this issue Sep 24, 2019
@bdimcheff
Copy link

Install works with GO111MODULE=off so you ought to be able to install it that way if you just need the binary. If you're actually using golangci-lint from another module, you should be able to fix it for your module with:

replace github.com/go-macaron/cors v0.0.0-20190309005821-6fd6a9bfe14e9 => github.com/go-macaron/cors v0.0.0-20190418220122-6fd6a9bfe14e
replace github.com/census-instrumentation/opencensus-proto v0.1.0-0.20181214143942-ba49f56771b8 => github.com/census-instrumentation/opencensus-proto v0.0.3-0.20181214143942-ba49f56771b8

crdueck added a commit to Wattpad/ship-it that referenced this issue Sep 24, 2019
A broken transitive dependency of golangci-lint is causing our build to
fail when running with GO111MODULE=on. Until it's fixed upstream,
getting the binary with modules turned off avoids the issue.

golangci/golangci-lint#730
@tpounds tpounds changed the title Cannot go get from master Cannot go get due to invalid pseudo-version Sep 24, 2019
@tpounds tpounds added the bug Something isn't working label Sep 24, 2019
@tpounds tpounds self-assigned this Sep 24, 2019
@jirfag jirfag closed this as completed in c427c61 Sep 24, 2019
@listx
Copy link

listx commented Sep 24, 2019

Thanks for this, I can just do GO111MODULE=on go get github.com/golangci/golangci-lint/cmd/golangci-lint@c427c61 and it works now.

EDIT: Oops, meant to comment in PR #736, not the issue. Oh well.

@tpounds
Copy link
Contributor

tpounds commented Sep 24, 2019

@listx Thanks for confirming the fix works for you.

crdueck added a commit to Wattpad/ship-it that referenced this issue Sep 25, 2019
A broken transitive dependency of golangci-lint is causing our build to
fail when running with GO111MODULE=on. Until it's fixed upstream,
getting the binary with modules turned off avoids the issue.

golangci/golangci-lint#730
crdueck added a commit to Wattpad/ship-it that referenced this issue Sep 25, 2019
Turn off modules to workaround this issue:
golangci/golangci-lint#730

increase the deadline from 1m -> 5m, we were seeing "deadline exceeded"
errors causing build failures
crdueck added a commit to Wattpad/ship-it that referenced this issue Sep 25, 2019
* Add bulk commit functionality to ECR reconciler

* Add 'image' internal package

This package provides the 'image.Ref' type: a reference to a remote
container image

* Add unstructured.VisitOne func

This func is used to traverse and mutate unstructured yaml data
represented as `yaml.MapSlice`. It's used to make order-preserving edits
to yaml files.

* Add ChartEditor implementation

The ChartEditor provides a method to update HelmRelease yaml files,
belonging to a specified Helm chart in Github, to use a desired image.
It batches the changes for a single image into one commit.

* Update syncd to use the new ChartEditor and image types

* Fixup golangci-lint Travis job

Turn off modules to workaround this issue:
golangci/golangci-lint#730

increase the deadline from 1m -> 5m, we were seeing "deadline exceeded"
errors causing build failures

* go mod tidy

* Remove unused github env vars in ship-it-api config

* Remove unused github secrets from ship-it-api

The github secrets are not needed by the api, only syncd. For now, it's
assuming the secret is managed outside the chart, hence `existingSecretName`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

7 participants