prometheus: promql Go import problem: use of vendored package not allowed
What did you do?
I’ve tried to import the github.com/prometheus/common/model
package so I can construct a promql.AlertStmt
from scratch. Here is the demo code that I’m using:
package main
import (
"github.com/prometheus/common/model"
"github.com/prometheus/prometheus/promql"
)
func main() {
_ = &promql.AlertStmt{
Annotations: model.LabelSet{},
}
}
Building this package is not possible because promql
uses a vendored package and thus I’ve got this error:
./demo.go:10: cannot use "github.com/prometheus/common/model".LabelSet literal (type "github.com/prometheus/common/model".LabelSet) as type "github.com/prometheus/prometheus/vendor/github.com/prometheus/common/model".LabelSet in field value
This is ok, because they really are two different packages (one is vendored, and the other one is pulled by me and put into GOPATH), but if you go and use the vendored import path:
package main
import (
"github.com/prometheus/prometheus/promql"
"github.com/prometheus/prometheus/vendor/github.com/prometheus/common/model"
)
func main() {
_ = &promql.AlertStmt{
Annotations: model.LabelSet{},
}
}
Now you get the error:
package demo
imports github.com/prometheus/prometheus/vendor/github.com/prometheus/common/model: use of vendored package not allowed
What did you expect to see?
I want to be able to create a custom promql.AlertStmt
with the Annotations
field
What did you see instead? Under which circumstances?
As described above, it’s not possible to create such a value
Environment
go version go1.6 darwin/amd64
- System information:
Darwin Fatihs-MacBook-Pro.local 15.5.0 x86_64
- Prometheus version:
I’m using latest master with Git SHA a08943e6d347119bfb1b50e738fca577e5733290
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 16 (13 by maintainers)
Commits related to this issue
- Removes vendor folder This was potentially causing type conflicts in consumer libraries. See https://github.com/prometheus/prometheus/issues/1720 — committed to upsight/franz by noonat 7 years ago
- Removes vendor folder This was potentially causing type conflicts in consumer libraries. See https://github.com/prometheus/prometheus/issues/1720 — committed to upsight/franz by noonat 7 years ago
- Removes vendor folder This was potentially causing type conflicts in consumer libraries. See https://github.com/prometheus/prometheus/issues/1720 — committed to upsight/franz by noonat 7 years ago
- Removes vendor folder This was potentially causing type conflicts in consumer libraries. See https://github.com/prometheus/prometheus/issues/1720 — committed to upsight/stop by noonat 7 years ago
There’s no such thing as “meant as library” if we design each package in a manner that it exposes a well-designed API for the behavior it aims to implement. Locality of packages is merely to simplify making modifications as we need them ourselves (i.e. no constant revendoring) and to indicate to potential users the API instability that comes with it.
I’m not comfortable moving PromQL out at this point. It has an API that makes it useful for external use cases but is not there yet for a stable package.
I think we have to count on vendor tooling here to work around the general issue. Especially since this is not PromQL specific and will come up again and again. Having 40 repos with distinct libraries for a project does not scale for any Go project out there.