8000 Cannot load github.com/Azure/azure-sdk-for-go/arm/compute · Issue #5590 · prometheus/prometheus · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Cannot load github.com/Azure/azure-sdk-for-go/arm/compute #5590

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.

Sign up for GitHub

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

Jump to bottom
Closed
alexrudd opened this issue May 22, 2019 · 9 comments
Closed

Cannot load github.com/Azure/azure-sdk-for-go/arm/compute #5590

alexrudd opened this issue May 22, 2019 · 9 comments

Comments

@alexrudd
Copy link
alexrudd commented May 22, 2019 •
edited
Loading

Bug Report

What did you do?

Tried to import github.com/prometheus/prometheus/config for use in my own application:

package main

import "github.com/prometheus/prometheus/config"

func main() {
	config.LoadFile("./prometheus.yml")
}

What did you expect to see?

successful compilation.

What did you see instead? Under which circumstances?

$ go version
go version go1.12.5 linux/amd64
$ go build
go: finding github.com/Azure/azure-sdk-for-go/arm/compute latest
go: finding github.com/Azure/azure-sdk-for-go/arm/network latest
go: finding github.com/Azure/azure-sdk-for-go/arm latest
build github.com/myorg/myapp/prometheus: cannot load github.com/Azure/azure-sdk-for-go/arm/compute: cannot find module providing package github.com/Azure/azure-sdk-for-go/arm/compute

Environment

  • System information:
$ uname -srm
Linux 4.4.0-17763-Microsoft x86_64

Notes

This might be something to do with #4468 - in that issue, volatile third-party dependencies is the reason given for still using the vendor directory. I don't see why this is necessary when a requirement can be pinned to a specific commit in go.mod?

The reason I'm trying to do all this is that I need to a way to configure Prometheus targets at launch time, preferably by environment variables. I don't have the ability to mount in a configuration file (running in docker), and the targets vary depending on environment so can't bake the config into the image. My plan is to use an entrypoint script to generate a custom config file based off of environment variables... if there's an easier way to do this, please let me know.
@simonpasquier
Copy link
Member

I don't grasp all the reasons why this is happening but AFAICT you need to go get a specific version of github.com/prometheus/prometheus before building your project.

go mod init example.com/foo
cat <<EOF > main.go
package main

import "github.com/prometheus/prometheus/config"

func main() {
  config.LoadFile("./prometheus.yml")
}
EOF
go get github.com/prometheus/prometheus@v2.9.2+incompatible
go build

@alexrudd
Copy link
Author

you need to go get a specific version of github.com/prometheus/prometheus before building your project.

Yes this does work! Thanks for the quick solution :)

I wonder what commit the default "latest" go get is resolving to. My understanding was that it would use the tag with the highest semvar value... I wonder if it's confused by the go.mod name not including the major version.
< 8000 div class="d-flex">

@beorn7
Copy link
Member
beorn7 commented May 22, 2019

I can see how that's a problem if people use packages from prometheus/prometheus.

What would happen if we simply put the v2 into the module name? It was discussed (and cautiously dismissed) before, but I'm not so sure about the downsides of it.

@alexrudd
Copy link
Author

I'm not familiar enough with go modules to be sure. It might be that imports would then need to include the v2 suffix. It should be possible to repro this in a throw-away repository to better understand the impact. I can give this a go when I have some time.

@simonpasquier
Copy link
Member

I think I understand why Go picks up v2.5.0 of github.com/prometheus/prometheus if you don't specify anything else: as our module doesn't end up with .../v2, Go chooses the last version without a go.mod file (eg v2.5.0). Then Go tries to resolve the github.com/Azure/azure-sdk-for-go/arm/compute dependency but fails (FWIW we used an old version of the Azure SDK, the package doesn't exist anymore in the master branch and Go doesn't know where to find it). When you require explicitly a module-aware version of Prometheus then Go gets all the dependency versions from go.mod and doesn't have to guess anything.

When we switched to Go modules, we didn't follow the general recommendation to increment our major version (eg github.com/prometheus/prometheus/v3). Adding a /v2 suffix to the module name now might lead to another class of problems (for instance it could hurt other dependency managers). I guess we'll get this fixed when releasing Prometheus v3.

@alexrudd
Copy link
Author
alexrudd commented 8000 May 23, 2019

This makes sense, thanks for your help!

@beorn7
Copy link
Member
beorn7 commented May 23, 2019

So let's keep that in mind when releasing Prom 3.0.0, whenever that might be.
For now, the only consolation is that not many will use the packages from prometheus/prometheus from outside of the repo.
I'll close this issue as the immediate issue is clarified now.

@beorn7 beorn7 closed this as completed May 23, 2019
@t0mk t0mk mentioned this issue Sep 24, 2019
Closed
@codestation
Copy link

So, is there a workaround? Go 1.13 doesn't accept +incompatible on go get anymore

invalid version: +incompatible suffix not allowed: module contains a go.mod file, so semantic import versioning is required.

I want to use github.com/prometheus/prometheus/discovery to write a custom sd_config but cannot import the module.

@simonpasquier
Copy link
Member

Since Go 1.13, you need to specify the commit SHA. For v2.13.1:

go get github.com/prometheus/prometheus@6f92ce56053866194ae5937012c1bec40f1dd1d9

@krilor krilor mentioned this issue Mar 24, 2020
Closed
@lock lock bot locked and limited conversation to collaborators Apr 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@codestation @simonpasquier @alexrudd @beorn7
0