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

Most upvoted comments

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.