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

  From: "(unmatched-parenthesis" <paren@disroot.org>

* gnu/packages/golang.scm (go-github-com-google-shlex): New variable.
---
 gnu/packages/golang.scm | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)
  

On 03-08-2022 14:04, ( via Guix-patches via wrote:

> +    (arguments
> +     (list #:import-path "github.com/zenhack/go.notmuch"
> +           ;; XXX: Tests require you to download fixtures from the Internet.
> +           ;; See<https://github.com/zenhack/go.notmuch/blob/master/Makefile>.
> +           #:tests? #f))
> +    (propagated-inputs (list notmuch))
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?

> From: "(unmatched-parenthesis"<paren@disroot.org>
>
> * 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.

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
  * [...]

Like, if I would properly review (including checking the source code) 
this patch series and didn't know some of those were reviewed 
previously, then I would have to do the review again even though that's 
double work better spent elsewhere and if I later discover these were 
actually reviewed previously, that doesn't sound good for motivation to me.

And even though I know some of those have been submitted and reviewed 
previously, I don't remember which ones exactly and to which degree 
(only superficial checks like checking synopsis, description and 
#:tests?, or also source code checks, ...), so if I were to review this 
(*), I would have to look up the old patches and reviews, see which ones 
were reviewed previously and to what degree, look if changes have been 
made (e.g. changing which commit to use) that invalidated the review, 
..., which is not motivating to me.

(*) 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, ...

Greetings,
Maxime.
  

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.

    -- (