[go-nuts] [ANN] godoc: allow for lists, links, and rudimentary text styling [proposal].

2019-11-28 Thread Wojciech S. Czarnecki
I would like to announce a "rich godoc syntax" proposal. https://github.com/golang/go/issues/35896 Please do NOT reply to this announce here. The issue/35896 tracker is a proper venue to discuss proposals. Thank you, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message

[go-nuts] Re: eg-based pkg/errors to x/xerrors migration tool?

2019-11-28 Thread Sebastien Binet
On Tue, Nov 19, 2019 at 9:34 AM Sebastien Binet wrote: > hi there, > > before I try my hand to this, has anyone already written an eg-based tool > to (almost?) entirely automatically migrate a package from pkg/errors to > x/xerrors? > > non eg-based tools also accepted :) > found this one: - ht

[go-nuts] ANN: rollpwd - a dynamic password generator

2019-11-28 Thread R Srinivasan
all another practical and useful tool I used go for - targeting embedded linux devices at one end and a conventional windows/linux platform in the other. Hoping it will be useful by itself or as an example projectlet: https://github.com/RajaSrinivasan/rollpwd.git Best, Srinivasan -- You rece

[go-nuts] Re: early close of http.Client's Response.Body

2019-11-28 Thread Kevin Powick
You may find the following articles on http.Client useful. https://medium.com/hackernoon/avoiding-memory-leak-in-golang-api-1843ef45fca8 http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/index.html#close_http_resp_body https://tleyden.github.io/blog/2016/11/21/tuning-the-go-h

Re: [go-nuts] Re: Unable to lock versions when converting to go.mod

2019-11-28 Thread Brian Candler
Many thanks Axel. The problem isn't github.com/aperum/nrpe - that doesn't have any dependencies of its own outside of the standard library. However, the following three weren't vendored either: github.com/prometheus/client_golang/prometheus github.com/prometheus/client_golang/prometheus/promht

Re: [go-nuts] Re: Unable to lock versions when converting to go.mod

2019-11-28 Thread 'Axel Wagner' via golang-nuts
FWIW (I'm not saying that the output couldn't be more helpful): I got to the conclusion of what the problem was by looking at the output of `go build` you posted: go: finding github.com/aperum/nrpe latest It *does* tell you that it's trying to fetch a new module here and which. On Thu, Nov 28,

Re: [go-nuts] Re: Unable to lock versions when converting to go.mod

2019-11-28 Thread 'Axel Wagner' via golang-nuts
Hi, you are importing github.com/aperum/nrpe, but you don't vendor it or mention it in vendor.json. go mod init synthesizes a go.mod from vendor.json, using all versions you use there. Note that it doesn't mention nrpe. You then do a `go build`, which sees an import from a module not mentioned in

[go-nuts] Re: Unable to lock versions when converting to go.mod

2019-11-28 Thread Brian Candler
I *think* I got to the bottom of this. It turns out the nrpe_exporter.go main module imports some non-vendored dependencies: - github.com/aperum/nrpe - github.com/prometheus/client_golang/prometheus - github.com/prometheus/client_golang/prometheus/promhttp - github.com/prometheus/co

[go-nuts] Re: Unable to lock versions when converting to go.mod

2019-11-28 Thread Brian Candler
I got a private reply saying to try "go mod why -m github.com/prometheus/common" Starting with the original go.mod, I get different answers the first and second time I run it - by which time, go.mod contents have been updated. $ go mod why -m github.com/prometheus/common go: finding github.com/