On 03-08-2022 14:04, ( via Guix-patches via 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?+ (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))
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:
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.