Latest commit broken

[atombender]

$ go get -u github.com/prometheus/prometheus
# github.com/prometheus/prometheus/web/blob
src/github.com/prometheus/prometheus/web/blob/blob.go:28: undefined: files

Since go get doesn't allow you to specify a revision, it would be great if you could keep master stable.

[beorn7]

One does not simply go get Prometheus! :)

Unfortunately, we still need some Makefile magic. You have to clone the prometheus/prometheus repository normally from Github, cd into it and type make.

[juliusv]

Hey, we keep master stable (at least we try), but the problem you're encountering here is simply that Prometheus isn't go-gettable (not yet, at least). The reason is that we dynamically generate some files from the Makefile:

• web assets are generated into files.go to embed them into the binary (the missing file you're seeing)
• build information (revision, user/hostname, version, ...) is put into build.go to be displayed on Prometheus' status page
• parser/lexer files are generated (but they're checked in, so only need to be rebuilt when changed)
• the config protobuf code is generated from config.proto (but also checked in)

We could check in files.go, but the build information can't really be checked in unless we keep some dummy version of it around that doesn't contain any real build info...

[atombender]

Understood. Thanks for the explanation. I was simply following the instructions here. Then I found that I could just run the go install github.com/prometheus/prometheus/tools/rule_checker command without building Prometheus.

[vtolstov]

May be use new go generate ability and generate files for protobuf and for assets? I see for assets some examples in go mailing list.
In this case go get can be used to download and install...

[juliusv]

@vtolstov That's a good suggestion, and I think that should work. It would mainly have to create the build.go, since everything else could be checked in (or also be go-generated). I filed an issue for it: #548

The other thing the Makefile does for us is that it enforces a specific Go version, and it also sets up GOPATH with the vendored deps correctly (we didn't use rewriting of dependency paths for the vendoring). That would also need to change. Hm...

[vtolstov]

@juliusv i'm prefer rewriting import path like camlistore for example doing.
In this case i don't need to use godep or something like this, and able to go get my packages and binaries. So i recommend this =)

[juliusv]

Yeah, that's probably fine. I'll discuss this with the others :)

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.