[bug#55903] [bug#56939] [PATCH 31/41] gnu: Add go-github-com-google-shlex.

[(]

On Wed Aug 3, 2022 at 4:38 PM BST, Maxime Devos wrote:
> Can we just substitute* in the appropriate library reference or whatever 
> is the Go equivalent instead of propagating?  Maybe in in configList.go, 
> we can replace -lnotmuch by -l/gnu/store/.../libnotmuch.so or add a 
> -L/gnu/store/... there?
Good point! I'll try that.

> > * gnu/packages/golang.scm (go-github-com-google-shlex): New variable.
> > ---
> >   gnu/packages/golang.scm | 23 +++++++++++++++++++++++
> >   1 file changed, 23 insertions(+)
> >
> > diff --git a/gnu/packages/golang.scm b/gnu/packages/golang.scm
> > index fd2335b61a..9959dd118c 100644
> > --- a/gnu/packages/golang.scm
> > +++ b/gnu/packages/golang.scm
> > @@ -10720,3 +10720,26 @@ (define-public go-github-com-lithammer-fuzzysearch
> >        "A speedy fuzzy matching package for Go inspired by the JavaScript
> >   library bevacqua/fuzzysearch.")
> >       (license license:expat)))
> > +
> > +(define-public go-github-com-google-shlex
> > +  (package
> > +    (name "go-github-com-google-shlex")
> > +    (version "0.0.0-20191202100458-e7afc7fbc510")
>
> Why has the commit and description been changed since 
> <https://issues.guix.gnu.org/37444>? The change in synopsis seems good 
> to me though.
I never referenced that issue in the making of this patchset :) I'll
change its description to that issue's version if you wish.

> Also, there are multiple patches adding go-github-com-google-shlex now 
> -- as I've asked in the past, can we stop doing that, or at least add a 
> pointer to the previous version to avoid double work for reviewers? 
> Likewise for:
>
>   * https://issues.guix.gnu.org/search?query=go-google-golang-org-protobuf
>   * https://issues.guix.gnu.org/search?query=go-github-com-xo-terminfo
>   * https://issues.guix.gnu.org/search?query=go-github-com-go-ini-ini
>   * https://issues.guix.gnu.org/search?query=go-github-com-emersion-go-pgpmail
>   * [...]
Maybe we could merge the patches adding those duplicate packages
standalone, without merging the other parts of the patchsets, so there
would be no need for anyone to write them again in the future.

> (*) To be clear, I consider it unlikely for me to seriously review Go 
> stuff in the future, as the Go world is full of forks that make no 
> attempt to contribute back to upstream, or many independent 
> implementations (see e.g. terminfo and shlex) where a single or maybe 
> two implementations would suffice, often there's a lack of attempting 
> backwards compatibility and version numbers are often just 0.0.0, ...
I know what you mean. It's a huge pain.

    -- (