On 02 Jun 23:24, Brian Brazil wrote: > On Tue, 2 Jun 2020 at 22:36, Tobias Schmidt <[email protected]> wrote: > > > > > > > On Tue, Jun 2, 2020 at 11:31 PM Julien Pivotto <[email protected]> > > wrote: > > > >> On 02 Jun 23:26, Tobias Schmidt wrote: > >> > On Tue, Jun 2, 2020 at 11:20 PM Julien Pivotto < > >> [email protected]> > >> > wrote: > >> > > >> > > On 27 May 07:50, Brian Brazil wrote: > >> > > > On Wed, 27 May 2020 at 07:05, Ben Kochie <[email protected]> wrote: > >> > > > > >> > > > > I was thinking about building an "exporter kit" repo that would > >> include > >> > > > > some helpful functions to reduce the amount of boilerplate needed > >> to > >> > > write > >> > > > > exporters. > >> > > > > > >> > > > > >> > > > I've thought such a thing would be useful for a long time, though my > >> > > > presumption was always that it would end up in client_golang as > >> it's not > >> > > > too far from instrumentation. > >> > > > > >> > > > In general I'm not a big fan of widespread proliferation of repos, > >> > > > particularly if it's lots of tiny repos. Even in the previous cases > >> where > >> > > > we managed to get the layering largely right, it still was quite a > >> pain > >> > > in > >> > > > terms of overhead and release management if the repos were being > >> actively > >> > > > developed. A single toolkit-y repo I could live with, I'd be > >> concerned if > >> > > > we were talking repos beyond that. > >> > > > > >> > > > Brian > >> > > > >> > > Do we have consensus on: > >> > > > >> > > - A new public repository in the Prometheus organisation > >> > > - That repository will contain go code that will be used by > >> Prometheus, > >> > > PGW, AM and Official exporters (including but not limited to tls) > >> > > - That repository will follow go semver and be public, therefore > >> > > be reusable by unofficial exporters too > >> > > > >> > > Should we name it: > >> > > - github.com/prometheus/exporter > >> > > - github.com/prometheus/toolkit > >> > > >> > > >> > What is the scope of a prometheus/toolkit repo in contrast to the > >> existing > >> > prometheus/common repo which already includes go pkgs used in other > >> > projects? We also already have prometheus/promu "Prometheus Utility > >> Tool". > >> > > >> > Would it be an option to just put the new package in prometheus/common? > >> > >> Common is internal code that is generally not intend to share or support > >> to the outside world (with the exception of expfmt). > >> > > > > Thanks for the info and apologies for the noise. Now I also found Björn's > > paragraph on this matter. I wouldn't immediately understand the scope of a > > toolkit repo next to the existing common and promu ones. > > > > I'd vote to make the "exporter" part clear in the name, but then repo > > itself is not an actual exporter. Maybe prometheus/exporter-toolkit? > > > > One thing to keep in mind is how this will look in terms of go imports, I'd > presume we'd have everything in sub-packages off the repo. > > Brian > >
https://github.com/prometheus/exporter-toolkit has been created. Let's PR README's and so on in the coming days. -- Julien Pivotto @roidelapluie -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200603220407.GA1221561%40oxygen.
