promlint: initial copy from github.com/prometheus/prometheus/util/pro…

[mdlayher]

…mlint

For discussion in prometheus/prometheus#5317.

Updates prometheus/prometheus#5317.

[mdlayher]

Do we ever update the copyright year when moving code around?

[mdlayher]

Is there a reason this is still testing with Go 1.7? We're up to 1.12 now, and IMHO supporting anything older than maybe 1.10 is not worth it.

[beorn7]

Is there a reason this is still testing with Go 1.7? We're up to 1.12 now, and IMHO supporting anything older than maybe 1.10 is not worth it.

That's probably stemming from the 1.7 support of prometheus/client_golang. The idea is to support it there for as long as it doesn't cause any overhead (besides having a line in our CI config). I think we should always support three or perhaps four versions back in client_golang, but we can support more as long as we aren't using any features that were only added in recent versions.

[mdlayher]

Four versions back would be 1.8, and all I need is 1.8 for sort.SliceStable. :)

But if it's really necessary to keep 1.7 support, I could add a temporary shim in here for 1.7 that calls sort.Slice instead, but then the sort output is not stable.

https://golang.org/pkg/sort/#Slice

Food for thought: the Go project's policy on version support: https://golang.org/doc/devel/release.html#policy.

Each major Go release is supported until there are two newer major releases. For example, Go 1.5 was supported until the Go 1.7 release, and Go 1.6 was supported until the Go 1.8 release.

Since I don't maintain these repositories, I will respect your choice, but TBQH I'm not sure we're doing our users a favor by supporting older versions of Go that are not supported by the upstream project.

EDIT: this is just my opinion, of course, and I don't intend to come off as brash or unreasonable. I just am wary of allowing folks to build code with versions of Go which may have vulnerabilities and etc. I'm not sure if the latest 1.x.x in those various patch series were safe from vulnerabilities discovered later on after they became unsupported.

[mdlayher]

Oops, just realized sort.Slice was also added in 1.8. I can do it the old-school way and use sort.Stable from 1.2 if you'd prefer that.

[beorn7]

As said, that kind of effort would totally a reason to drop 1.7 support in client_golang.

[mdlayher]

Right on, I wasn't sure if my workaround here qualified! I'll submit a couple of PRs for here and there.

[mdlayher]

prometheus/client_golang#546 and #176.

[brian-brazil]

As noted in prometheus/prometheus#5317, there's no reason to move this code here currently.

[mdlayher]

I wrote this as a general purpose library without any dependency on the Prometheus repository itself, and for lack of a better place, stuffed it into util/. Although prometheus/prometheus is the only org repository user of it, keeping it here doesn't really feel like the right place since it can be and is imported as a library in other projects as well.

[brian-brazil]

Being in common doesn't denote that code is a public API, common is for sharing among our repos.