Go get unknown revision error

What version of Go are you using (go version)?

go version go1.14.2 darwin/amd64

Does this issue reproduce with the latest release?

I don’t know how to repro this issue; it appears intermittently.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env

What did you do?

I created a new private repo on GitHub, populated it, and about ~10 minutes later attempted to go get it into another project on my local machine. This failed, and after several additional commands (below), I realized that the mod cache entry itself was corrupted.

Manually deleting the entry from the mod cache, then issuing the original command (command 1 below) again appears to have resolved the issue.

What did you expect to see?

That the module downloaded.

What did you see instead?

Below:

Command 1

GOPRIVATE=github.com/xxxx GIT_TERMINAL_PROMPT=1 go get -u github.com/xxxx/yyyy@master
go get github.com/xxxx/yyyy@master: github.com/xxxx/yyyy@master: invalid version: unknown revision master

Command 2

Same as command 1, yet without @master.

GOPRIVATE=github.com/xxxx GIT_TERMINAL_PROMPT=1 go get -u github.com/xxxx/yyyy
go get github.com/xxxx/yyyy: module github.com/xxxx/yyyy: git ls-remote -q origin in /Users/zzzzz/go/pkg/mod/cache/vcs/916ad3826f1a995d5f8341487e6563a6c380c2d8aef514d8034f962111c7b16c: exit status 128:
	fatal: 'origin' does not appear to be a git repository
	fatal: Could not read from remote repository.

	Please make sure you have the correct access rights
	and the repository exists.

Command 3

Same as command 2, yet without GOPRIVATE, GIT_TERMINAL_PROMPT.

go get github.com/xxxx/yyyy: module github.com/xxxx/yyyy: git ls-remote -q origin in /Users/zzzzz/go/pkg/mod/cache/vcs/916ad3826f1a995d5f8341487e6563a6c380c2d8aef514d8034f962111c7b16c: exit status 128:
	fatal: 'origin' does not appear to be a git repository
	fatal: Could not read from remote repository.

	Please make sure you have the correct access rights
	and the repository exists.

Mitigation

After trying a number of things, I decided to just manually purge the entry from the cache.

cd $HOME/go/pkg/mod/cache/vcs
rm 916ad3826f1a995d5f8341487e6563a6c380c2d8aef514d8034f962111c7b16c.info
rm 916ad3826f1a995d5f8341487e6563a6c380c2d8aef514d8034f962111c7b16c.lock
rm -rf ./916ad3826f1a995d5f8341487e6563a6c380c2d8aef514d8034f962111c7b16c/

After that, reissuing command 1 (above), resulted in the module being downloaded successfully as originally expected. Note that both GOPRIVATE and @master are present in this successful attempt.

GOPRIVATE=github.com/xxxx GIT_TERMINAL_PROMPT=1 go get -u github.com/xxxx/zzzz@master
go: downloading github.com/xxxx/yyyy v0.0.0-20201218021721-ab6f5cd5f994
go: github.com/xxxx/yyyy master => v0.0.0-20201218021721-ab6f5cd5f994
go: golang.org/x/sys upgrade => v0.0.0-20201214210602-f9fddec55a1e
go: golang.org/x/crypto upgrade => v0.0.0-20201217014255-9d1352758620
go: github.com/pkg/errors upgrade => v0.9.1
go: github.com/sirupsen/logrus upgrade => v1.7.0

Discussion

The documentation strongly communicates that the mod cache is immutable and shouldn’t be touched. The tooling reinforces that by treating the mod cache as an all-or-nothing construct — go clean --modcache drops the entire thing.

However, with this issue and mitigation, I’ve learned that individual entries get corrupted in a way that can be corrected by surgically deleting a specific cache entry.

It would be extremely helpful if the the go clean command were to be updated to allow an individual module to be purged from the mod cache (and for the various go get error paths and/or documentation to suggest that purging a single module from the cache can resolve issues).

How To Fix Go Mod Unknown Revision

After the introduction of Go mod you may have worked with Go modules and private repositories. When working on a Go project that uses the new Go modules package management and versioning system and working exclusively with public packages you won’t generally encounter any major issue.

However when trying to import a Go package that is into a private repository you might encounter problems when running Go build or Go modules commands. You might see an issue as follows:

If you have had a similar error you are not alone. This means that Go modules can’t rightfully access a private package.

How to resolve Go mod unknown revision when accessing private repositories

1. Make sure you have set GO111MODULES

Make sure you are using Go modules correctly this tells Go to use Go modules in case you are running an old version or Go or you have disabled Go modules by mistake. This is necessary for running the next steps.

2. Add your organisation private repository to GOPRIVATE

The Go team has rightfully thought about the possiblity of having private packages when working with Go mod and created a help tool to describe such scenario

The next step should therefore be as follows, which sets our private repository as “private” using the GOPRIVATE env variable

3. Make sure your git configuration is appropriate for private repositories

Go mod uses git under the hood to retrieve remote package information. You should therefore tell git how to access private packages by updating the git configuration

This will allow your git client and consequently Go mod to use your ssh key to access and authenticate with github and access the private repository

4. Make sure to create a personal access token if using 2FA

In github specifically if you are using 2FA for your organisation, using your ssh key won’t work in this case and you will have instead to create a personal access tokenand use that to access your private repository

Источник

cmd/go: «unknown revision» error due to git client corruption in the Go module cache #43260

What version of Go are you using ( go version )?

go version go1.14.2 darwin/amd64

Does this issue reproduce with the latest release?

I don’t know how to repro this issue; it appears intermittently.

What operating system and processor architecture are you using ( go env )?

What did you do?

I created a new private repo on GitHub, populated it, and about

10 minutes later attempted to go get it into another project on my local machine. This failed, and after several additional commands (below), I realized that the mod cache entry itself was corrupted.

Manually deleting the entry from the mod cache, then issuing the original command (command 1 below) again appears to have resolved the issue.

What did you expect to see?

That the module downloaded.

What did you see instead?

Command 1

Command 2

Same as command 1, yet without @master .

Command 3

Same as command 2, yet without GOPRIVATE , GIT_TERMINAL_PROMPT .

Mitigation

After trying a number of things, I decided to just manually purge the entry from the cache.

After that, reissuing command 1 (above), resulted in the module being downloaded successfully as originally expected. Note that both GOPRIVATE and @master are present in this successful attempt.

Discussion

The documentation strongly communicates that the mod cache is immutable and shouldn’t be touched. The tooling reinforces that by treating the mod cache as an all-or-nothing construct — go clean —modcache drops the entire thing.

However, with this issue and mitigation, I’ve learned that individual entries get corrupted in a way that can be corrected by surgically deleting a specific cache entry.

It would be extremely helpful if the the go clean command were to be updated to allow an individual module to be purged from the mod cache (and for the various go get error paths and/or documentation to suggest that purging a single module from the cache can resolve issues).

The text was updated successfully, but these errors were encountered:

Источник

cmd/go: unknown revision when using semver tag for module in subdirectory #31045

What version of Go are you using ( go version )?

Does this issue reproduce with the latest release?

Yes. It also reproduces with go1.12beta2 .

What operating system and processor architecture are you using ( go env )?

What did you do?

In a local go module, I tried to require a specific tagged version of a go module available from a subdirectory in a remote repo. go build returns an error giving unknown revision . When I remove the require and let it figure out the dependency automatically, it adds the module to the go.mod using a pseudo-version despite being able to use a tagged version when requiring a separate module that resides at the same remote repo’s root. Here is a complete repro using github.com/burnson/gomoduletest as the remote repo. Step 1 creates the remote repo from scratch and Step 2 reproduces the pseudo-version behavior and build error when an explicit tag is used instead.

What did you expect to see?

In the local module test, I expected to see go build tag subpackage with the v1.0.0 semver tag I pushed to the remote repo in go.mod . Furthermore, when I edit go.mod to explicitly use v1.0.0 , I expect it to find the revision when I go build .

What did you see instead?

go build finds the subpackage module but writes it using a pseudo-version in go.mod . If I override that with the tagged version v1.0.0 , I get an unknown revision error. However, the revision is detected for the module that resides at the remote repo root, which is a contradiction.

The text was updated successfully, but these errors were encountered:

Источник

cmd/go: go get failing with vague error ‘unknown revision v0.0.0’ with kubernetes #32776

What version of Go are you using ( go version )?

Does this issue reproduce with the latest release?

I am not sure (I am 1 patch version away from the latest release)

What operating system and processor architecture are you using ( go env )?

What did you do?

go get ./. in the project root

What did you expect to see?

I expected to see a list of all my dependencies being downloaded successfully

What did you see instead?

The text was updated successfully, but these errors were encountered:

The errors such as go: k8s.io/api@v0.0.0: unknown revision v0.0.0 are the more specific errors.

@thepudds is there a workaround to this issue?

Looks like go get doesn’t look into replace directives?

Looks like go get doesn’t look into replace directives?

replace directives in modules other than the main module are ignored when building the main module.

So a module-based consumer of k8s.io/api for example does not use any replace directives found in the go.mod file of k8s.io/api.

The main module’s go.mod file defines the precise set of packages available for use by the go command, through require, replace, and exclude statements. Dependency modules, found by following require statements, also contribute to the definition of that set of packages, but only through their go.mod files’ require statements: any replace and exclude statements in dependency modules are ignored. The replace and exclude statements therefore allow the main module complete control over its own build, without also being subject to complete control by dependencies.

k8s.io/kubernetes is not primarily intended to be consumed as a module. Only the published subcomponents are (and go get works properly with those).

If you want to consume k8s.io/kubernetes as a module, you’d probably need to add require directives for matching versions of all of the subcomponents, rather than using go get

@liggitt I am not using kubernetes/kubernetes. I am using client-go

These are some of the ones I am using

@joshmsamuels could you try to put together a minimal set of steps to reproduce, ideally starting with an empty module? (E.g., something like cd $(mktemp -d); go mod init tempmod; , etc.)?

@thepudds Should I like make a main.go for that then?

It sounds like the Go command is working as intended, but let’s make sure we can reproduce this before closing. @joshmsamuels please do post a minimal example to help us see the same error. A gist or a small repo with a go.mod and a couple .go files would be fine.

As others have pointed out, replace directives are only effective for builds within the module where they appear. So if you check out k8s.io/kubernetes , the replace directives there will work, but not replace directives in other go.mod files.

Kubernetes has a complicated system for managing dependencies, and they have a lot of replace directives. Some of their dependencies are required at version v0.0.0 (which doesn’t exist): those requirements must be replaced. This prevents k8s.io/kubernetes from being a requirement of other modules.

However, if you aren’t depending on k8s.io/kubernetes , you shouldn’t have a problem.

I am not using kubernetes/kubernetes

Источник

cmd/go: «unknown revision» error is misleading if the entire repo can’t be found #47028

What version of Go are you using ( go version )?

What version of Git are you using ( git version )?

What version of GitLab are you using ( Help )?

Private Instance of:

Does this issue reproduce with the latest release?

Yes. Also, in version 1.16.3.

What operating system and processor architecture are you using ( go env )?

What did you do (with results)?

There is an application that was developed and built on a Linux server. We wanted to build natively on Windows.

What did you expect to see?

When I perform the same actions on Linux (and I delete the go/pkg directory first), I would expect to see:
go: downloading gitlab.mydomain.com/group/subgroup/dependency v1.0.4
.

Further research.

I deleted the go.mod and go.sum files. I performed a go mod init and then a go mod tidy.

It appears as if Go is requesting the subgroup as a repository?! That is not correct. I am sure there is an underlying reason for this behavior, but it leaves users unclear about root cause.

I performed a git clone https://gitlab.mydomain.com/group/subgroup/dependency.git successfully. So, a direct git clone command was successful. As I had setup a credential helper, this was even non-interactive. It left me unsure about root cause, appearing that access was not an issue.

I did some online research and found #34094. This seemed relevant but did not provide immediate clarity for resolving the issue. There was some mention about non-support for interactive logins. There was also mention about private repositories, which is how dependency.git was setup.

Finally, I found #24606 go get on Windows. By setting up the _netrc in my User directory, I was able to resolve the issue.

If I am understanding the Go behaviour properly, it appears as if Go is accessing GitLab directly without Git (as git is setup with a credential helper) and having an access issue. However, it is not displaying any message indicating an access issue. It would be nice to have a message that displays some sort of access failure instead of this fallback that attempts to git a non-existent repository.

The text was updated successfully, but these errors were encountered:

Источник

cmd/go: «error loading module requirements» from ‘go mod download’ #29213

Comments

TPTan96 commented Dec 13, 2018

What version of Go are you using ( go version )?

What operating system and processor architecture are you using ( go env )?

What did you do?

Create an image docker

What did you expect to see?

What did you see instead?

Step 6/10 : RUN go mod download
—> Running in 414efa3e565e
go: finding github.com/gorilla/mux v1.6.2
go: github.com/gorilla/mux@v1.6.2: unknown revision v1.6.2
go: error loading module requirements
The command ‘/bin/sh -c go mod download’ returned a non-zero code: 1

The text was updated successfully, but these errors were encountered:

agnivade commented Dec 13, 2018

Please mention the exact steps so that we can reproduce this at our end.

What is the Dockerfile ? What is the repo ? Is there a go.mod ?

This is what I get —

gopherbot commented Jan 14, 2019

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

varuntechie commented May 6, 2019

Facing the same error
» go clean -modcache
go: finding github.com/pkg/errors v0.8.1
go: finding github.com/go-sql-driver/mysql v1.4.1
go: finding github.com/go-goracle/goracle v2.1.14+incompatible
go: github.com/go-goracle/goracle@v2.1.14+incompatible: unknown revision v2.1.14
go: github.com/go-sql-driver/mysql@v1.4.1: unknown revision v1.4.1
go: github.com/pkg/errors@v0.8.1: unknown revision v0.8.1
go: finding gopkg.in/goracle.v2 v2.13.1
go: gopkg.in/goracle.v2@v2.13.1: unknown revision v2.13.1
go: error loading module requirement»

joshmsamuels commented Jun 24, 2019

I am also encountering this problem.

alwinmarkcf commented Jul 18, 2019

Some more information would be awesome like:

This message is just not useful

Integralist commented Sep 19, 2019

Yup I’m also getting this and it’s unclear why.

Источник

cmd/go: difficulty resolving ‘error loading module requirements’ with kubernetes #32864

Comments

medyagh commented Jul 1, 2019

What version of Go are you using ( go version )?

Does this issue reproduce with the latest release?

Yes, I am using latest.

What operating system and processor architecture are you using ( go env )?

What did you do?

in minikube go.mod I bumped k8s.io/kubernetes v1.11.3 to k8s.io/kubernetes v1.15.0

and I ran go mod tidy -v

What did you expect to see?

I expected it update my dependency or tell me what is blocking it form doing so.

What did you see instead?

go: error loading module requirements

The failing go.mod

The text was updated successfully, but these errors were encountered:

AlexRouSg commented Jul 1, 2019 •

Specifically this comment #32776 (comment)

k8s.io/kubernetes is not primarily intended to be consumed as a module. Only the published subcomponents are (and go get works properly with those).

If you want to consume k8s.io/kubernetes as a module, you’d probably need to add require directives for matching versions of all of the subcomponents, rather than using go get

medyagh commented Jul 1, 2019

Thanks for the response @AlexRouSg . I understand that I would need to add all the indirect modules myself but the error message on go mod tidy was not even remotely helping me. Or others that might have same issue.

I was hoping by adding -v I could get some more details. Is there any way go mod could provide more context or more helpful error message?

medyagh commented Jul 1, 2019

Plus I had the same issue when I was trying to use the sub package. ( Either client-go or kubectl)
I was able to solve my problem with go dep . I was hoping go mod could catch up with go dep

AlexRouSg commented Jul 1, 2019

The error message is actually:

The unknown revision v0.0.0 parts are the hints on what’s wrong. Do you have any suggestions on what would be a better message?

medyagh commented Jul 1, 2019 •

The unknown revision v0.0.0 parts are the hints on what’s wrong. Do you have any suggestions on what would be a better message?

in my go.mod file I have the commit ID for them for example ( 1f13a808da65 ) for k8s.io/client-go v0.0.0-20180806134042-1f13a808da65 , so I don’t undrestand why go mod thinks it has not been given a revision ?

and more importantly, if I revert back the k8s.io/kubernetes v1.15.0 version from 1.15.0 to 1.11.3 , it will not be yelling about unknown revision for any of them (including client-go) and worked fine. so it is inconsistent error and it failed to undrestand that the source of the problem is k8s.io/kubernetes v1.15.0 everything else is fine.

so I don’t think it is unknown revision since i have given the commit id to it.

AlexRouSg commented Jul 1, 2019 •

1.11.3 was before they added modules support so things just work the old way.

Источник

Go mod error loading requirements and unknown revisions #39475

Comments

leguminosa commented Jun 9, 2020

What version of Go are you using ( go version )?

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using ( go env )?

What did you do?

What did you expect to see?

What did you see instead?

The text was updated successfully, but these errors were encountered:

bcmills commented Jun 10, 2020 •

Per the Go project’s release policy, go 1.12.7 has been unsupported since 2020-02-25 (when go 1.14 was released), and we have added workarounds for a number of git client bugs since 1.12.7.

Please try go1.14.4 (the current release) and let us know if this issue is still reproducible, and if so with which git client version.

leguminosa commented Jun 11, 2020 •

yes I installed gvm yesterday shortly after creating this ticket,

and then go mod tidy -v succeed.

And I ran those commands from my (zsh) terminal outside vscode.

Then I had problem when doing things from vscode terminal / tools (run go mod tidy -v , automated coverage test on save, problems tab) and when I check go version , go env from vscode terminal, it still shows 1.12.7 and old GOPATH (as opposed to new one by gvm)

What is the solution for those so that my vscode is aligned with the gvm ?

Then I also found gvm extension on vscode, I installed it, set the go to 1.13 like I did before, and finally the go version on vscode matches with the terminal outside vscode.

Is «downloading gvm extension on vscode» really is the proper solution I asked earlier?

bcmills commented Jun 11, 2020

I have no idea about gvm or how it works. Generally extensions like vscode should use whichever go command is first in $PATH , so you might check what PATH you’re running vscode with. (If you’re starting vscode using a GUI, typically that environment is set in your .profile script rather than .zshrc , and you’ll need to log out and back in to pick up changes.)

Источник

replace directive in parent causes, error loading module requirements #29376

Comments

komuw commented Dec 21, 2018

What version of Go are you using ( go version )?

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using ( go env )?

What did you do?

create this main.go file;

and ran;
go1.12beta1 run main.go

What did you expect to see?

success or a helpful error message

What did you see instead?

The text was updated successfully, but these errors were encountered:

komuw commented Dec 21, 2018

The module github.com/perlin-network/life has a replace directive in it’s go.mod file:
https://github.com/perlin-network/life/blob/28a99a6d79ec86732bd0eca66fe45c88f7f29bbc/go.mod#L3
that directive is ignored leading to this failure.

unfortunately, the error message doesn’t point out that it is as a result of an ignored replace directive in the parent module( github.com/perlin-network/life ) and thus making it hard to diagnose what is going on.

komuw commented Dec 21, 2018

go1.12beta1 run main.go

thee parent module github.com/komuw/meli has replacement; https://github.com/komuw/meli/blob/master/go.mod#L47-L53 that get ignored

komuw commented Dec 21, 2018

@gopherbot, please add label modules

bcmills commented Dec 21, 2018

The error message here describes exactly the problem: go: github.com/go-interpreter/wagon@v0.0.0: unknown revision v0.0.0 . There is, indeed, no such version tagged in the repository, and (by design) replacements have no effect unless the module containing the replace directive is the main module.

We should not point out that it is the result of an ignored replace directive, because replace directives from other modules are always ignored. The problem is the invalid version in the require directive, and it would exist even without the corresponding replace .

Arguably go mod tidy within github.com/perlin-network/life should either choose a valid version or report an error; it does not today, and that’s #29182.

bcmills commented Dec 21, 2018

The situation in github.com/komuw/meli is worse, because the module owner is specifying incompatible versions: the require section declares a dependency on github.com/docker/distribution v2.6.2+incompatible , but the replace section selects what appears to be a semantically older version ( v2.6.0-rc.1.0.20180820212402-02bf4a2887a4+incompatible ).

If that commit really is newer than v2.6.2 , then it should have a newer pseudo-version. In fact, that commit seems to have been tagged v2.7.0 , which gives you an upgrade path to fix the problem. The solution with docker/docker is similar: explicitly go get the master version rather than the latest semantic tag.

bcmills commented Dec 21, 2018 •

The problems in these cases are semantic defects in the declared requirements, not directly due to replace directives. We should do more to prevent those semantic defects, rather than attributing them to only-semi-related features that are working as documented.

bcmills commented Dec 21, 2018

I think the thing that will fix the semantic defects is #29182, or perhaps #26420 (comment). Closing as a duplicate of those.

Footer

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

go get: error loading module requirements #41

Comments

Niklao commented Apr 28, 2019

I am on latest release of Go And Buffalo
Follwing is the output of installation
Is this due to some outdated dependencies.
Following is the output :

go get -u github.com/gobuffalo/buffalo-auth
go: finding github.com/gobuffalo/attrs latest
go: finding github.com/serenize/snaker latest
go: finding golang.org/x/crypto latest
go: finding github.com/gobuffalo/meta latest
go: finding golang.org/x/sync latest
go: finding github.com/gobuffalo/logger latest
go: finding golang.org/x/tools latest
go: finding github.com/gobuffalo/licenser latest
go: finding github.com/markbates/oncer latest
go: finding github.com/sourcegraph/syntaxhighlight latest
go: finding github.com/ugorji/go/codec latest
go: finding golang.org/x/sys latest
go: finding github.com/armon/consul-api latest
go: finding golang.org/x/net latest
go: finding github.com/gobuffalo/gitgen latest
go: finding github.com/sourcegraph/annotate latest
go: finding github.com/gobuffalo/helpers latest
go: finding github.com/gobuffalo/syncx latest
go: finding github.com/google/pprof latest
go: finding gopkg.in/tomb.v1 latest
go: finding gopkg.in/check.v1 latest
go: finding golang.org/x/lint latest
go: finding github.com/shurcooL/highlight_diff latest
go: finding google.golang.org/genproto latest
go: finding github.com/prometheus/procfs latest
go: finding github.com/shurcooL/go latest
go: finding github.com/golang/glog latest
go: finding golang.org/x/oauth2 latest
go: finding golang.org/x/build latest
go: finding github.com/anmitsu/go-shlex latest
go: finding github.com/shurcooL/octicon latest
go: finding github.com/jellevandenhooff/dkim latest
go: finding honnef.co/go/tools latest
go: finding github.com/googleapis/gax-go v2.0.2+incompatible
go: finding github.com/shurcooL/home latest
go: finding github.com/neelance/astrewrite latest
go: finding github.com/tarm/serial latest
go: finding github.com/shurcooL/go-goon latest
go: finding github.com/shurcooL/github_flavored_markdown latest
go: finding github.com/shurcooL/events latest
go: finding dmitri.shuralyov.com/html/belt latest
go: finding dmitri.shuralyov.com/service/change latest
go: finding github.com/shurcooL/notifications latest
go: finding dmitri.shuralyov.com/state latest
go: finding github.com/shurcooL/users latest
go: finding github.com/bradfitz/go-smtpd latest
go: finding github.com/gregjones/httpcache latest
go: finding golang.org/x/time latest
go: finding github.com/shurcooL/highlight_go latest
go: finding github.com/shurcooL/httpgzip latest
go: finding github.com/shurcooL/gofontwoff latest
go: finding github.com/shurcooL/httpfs latest
go: finding github.com/coreos/go-systemd latest
go: finding github.com/shurcooL/httperror latest
go: finding github.com/golang/lint latest
go: finding github.com/flynn/go-shlex latest
go: github.com/golang/lint@v0.0.0-20190409202823-959b441ac422: parsing go.mod: unexpected module path «golang.org/x/lint»
go: sourcegraph.com/sourcegraph/go-diff@v0.5.1: parsing go.mod: unexpected module path «github.com/sourcegraph/go-diff»
go: finding golang.org/x/tools v0.0.0-20190114222345-bf090417da8b
go: finding github.com/shurcooL/issues latest
go: finding github.com/shurcooL/reactions latest
go: finding github.com/shurcooL/gopherjslib latest
go: finding github.com/shurcooL/issuesapp latest
go: finding golang.org/x/perf latest
go get: error loading module requirements

The text was updated successfully, but these errors were encountered:

frederikhors commented Jun 21, 2019

Execute go get -u github.com/gobuffalo/buffalo-auth outside project folder.

If it works please close this issue.

jameswang2015 commented Sep 11, 2019

I get the same issue, and I run go get command at $HOME folder. Please advise.
zwang-mac:

zwang$ go get gitlab.vm.domaintools.net/backend/gatheringsystem/remington go: finding gitlab.vm.domaintools.net/backend/gatheringsystem/remington latest go: finding github.com/beorn7/perks v1.0.1 go: finding github.com/googleapis/gax-go/v2 v2.0.5 go: finding golang.org/x/sys v0.0.0-20190507160741-ecd444e8653b go: finding golang.org/x/sys v0.0.0-20190801041406-cbf593c0f2f3 go: finding golang.org/x/sys v0.0.0-20190509141414-a5b02f93d862 go: finding golang.org/x/net v0.0.0-20190503192946-f4e77d36d62c go: finding golang.org/x/oauth2 v0.0.0-20190604053449-0f29369cfe45 go: finding golang.org/x/tools v0.0.0-20190506145303-2d16b83fe98c go: finding google.golang.org/appengine v1.5.0 go: finding golang.org/x/lint v0.0.0-20190409202823-959b441ac422 go: finding golang.org/x/net v0.0.0-20190108225652-1e06a53dbb7e go: finding github.com/hashicorp/golang-lru v0.5.1 go: finding github.com/knq/sysutil v0.0.0-20181215143952-f05b59f0f307 go: finding github.com/gobwas/httphead v0.0.0-20180130184737-2c6c146eadee go: finding github.com/golang/mock v1.3.1 go: finding go.opencensus.io v0.21.0 go: finding honnef.co/go/tools v0.0.0-20190418001031-e561f6794a2a go: finding cloud.google.com/go v0.34.0 go: finding google.golang.org/api v0.8.0 go: finding rsc.io/binaryregexp v0.2.0 go: finding github.com/json-iterator/go v1.1.7 go: finding gitlab.vm.domaintools.net/backend/gatheringsystem/gatherc/v3 v3.3.2 go: finding cloud.google.com/go v0.38.0 go: gitlab.vm.domaintools.net/backend/gatheringsystem/gatherc/v3@v3.3.2: unknown revision gatherc/v3.3.2 go: finding github.com/gobwas/pool v0.2.0 go: finding github.com/gobwas/ws v1.0.0 go: finding google.golang.org/genproto v0.0.0-20190801165951-fa694d86fc64 go: finding go.opencensus.io v0.22.0 go: finding golang.org/x/tools v0.0.0-20190628153133-6cdbf07be9d0 go: finding github.com/google/pprof v0.0.0-20190515194954-54271f7e092f go: finding cloud.google.com/go/datastore v1.0.0 go: finding github.com/mailru/easyjson v0.0.0-20180823135443-60711f1a8329 go: finding github.com/jstemmer/go-junit-report v0.0.0-20190106144839-af01ea7f8024 go: finding google.golang.org/genproto v0.0.0-20190502173448-54afdca5d873 go: finding google.golang.org/grpc v1.21.1 go: finding google.golang.org/grpc v1.20.1 go: finding github.com/mailru/easyjson v0.0.0-20190403194419-1ea4449da983 go: finding github.com/google/martian v2.1.0+incompatible go: finding golang.org/x/exp v0.0.0-20190510132918-efd6b22b2522 go: error loading module requirements

sio4 commented Jul 15, 2022

outdated. closing, but please feel free to reopen the issue if someone need help for the same issue.

Footer

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник