[bug#54335,11/14] gnu: Add go-google-golang-org-protobuf.
Commit Message
* gnu/packages/golang.scm (go-google-golang-org-protobuf): New variable.
---
gnu/packages/golang.scm | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
Comments
Dominic Martinez schreef op do 10-03-2022 om 22:47 [-0500]:
> +(define-public go-google-golang-org-protobuf
> + (package
> + (name "go-google-golang-org-protobuf")
A presumably compatible package is already packaged:
'go-github-com-gogo-protobuf'. Perhaps that package suffices?
Also, what's the difference with 'go-github-com-golang-protobuf-proto',
besides the unimportant difference in repository location?
Greetings,
Maxime
Dominic Martinez schreef op do 10-03-2022 om 22:47 [-0500]:
> + '(#:import-path "google.golang.org/protobuf"
> + ;; Source-only package
> + #:tests? #f
What has source code to do with tests? Tests can be in the form of
pre-compiled binaries, and tests are usually a part of the source code.
Also, there do appear to be a few tests, e.g. at
<https://github.com/protocolbuffers/protobuf-go/blob/3992ea83a23c00882339f33511074d251e19822c/testing/protocmp/util_test.go#L23>.
I don't know how to run them though.
Greetings,
Maxime.
Dominic Martinez schreef op do 10-03-2022 om 22:47 [-0500]:
> + (modify-phases %standard-phases
> + ;; Source-only package
> + (delete 'build))))
Why is the build phase removed? It seems to be just a Go library,
not some Rust-style circularity.
Greetings,
Maxime
Dominic Martinez schreef op do 10-03-2022 om 22:47 [-0500]:
> + #:tests? #f
I see a test in
<https://github.com/protocolbuffers/protobuf-go/blob/master/test.bash>.
Maxime Devos <maximedevos@telenet.be> writes:
>> + (modify-phases %standard-phases
>> + ;; Source-only package
>> + (delete 'build))))
>
> Why is the build phase removed? It seems to be just a Go
> library,
> not some Rust-style circularity.
As far as I can tell Go expects libraries to be source-only, so
I'm not sure what you would do in a build phase. I followed the
lead of the other Go library packages like go-golang-org-x-tools
(grep golang.scm for "Source-only package").
Maxime Devos <maximedevos@telenet.be> writes:
>> + '(#:import-path "google.golang.org/protobuf"
>> + ;; Source-only package
>> + #:tests? #f
>
> What has source code to do with tests? Tests can be in the form
> of
> pre-compiled binaries, and tests are usually a part of the
> source code.
I'm following the lead of other source-only Go packages which also
disable tests.
> I don't know how to run them though.
This is the issue I ran into; Guix seems to expect a build output
to run tests on.
Maxime Devos <maximedevos@telenet.be> writes:
>> +(define-public go-google-golang-org-protobuf
>> + (package
>> + (name "go-google-golang-org-protobuf")
>
> A presumably compatible package is already packaged:
> 'go-github-com-gogo-protobuf'. Perhaps that package suffices?
Annoyingly, the upstream Nebula source actively uses both
go-github-com-gogo-protobuf and go-google-golang-org-protobuf, and
they are not interchangeable.
> Also, what's the difference with
> 'go-github-com-golang-protobuf-proto',
> besides the unimportant difference in repository location?
go-github-com-golang-protobuf-proto was superceded by
go-google-golang-org-protobuf. Per the repo,
go-google-golang-org-protobuf contains "an updated and simplified
API, support for protobuf reflection, and many other improvements"
Dominic Martinez schreef op vr 11-03-2022 om 15:32 [-0500]:
> As far as I can tell Go expects libraries to be source-only, so
> I'm not sure what you would do in a build phase. I followed the
> lead of the other Go library packages like go-golang-org-x-tools
> (grep golang.scm for "Source-only package").
FWIW, there exist Go libraries that keep the default build phase,
e.g. go-github-com-hashicorp-go-version. Also, according
to comments in guix/build/go-build-system.scm, it is intended to
someday reuse the compiled build dependencies again (see
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32919>).
Also, perhaps the 'build' phase is currently largely useless for Go
libraries, I'd expect it to be a no-op in those cases, so I don't
expect it to be necessary to delete the build phase.
I expect that existing instances of (delete 'build) in golang.scm can
be removed, but it's not something I've ever actually tried, so I'm
not sure.
Greetings,
Maxime.
@@ -10017,3 +10017,42 @@ (define-public go-github-com-vishvananda-netlink
contained in the nl subpackage. This package attempts to provide a high-level
interface that is loosly modeled on the iproute2 cli.")
(license license:asl2.0)))
+
+(define-public go-google-golang-org-protobuf
+ (package
+ (name "go-google-golang-org-protobuf")
+ (version "1.27.1")
+ (source
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://go.googlesource.com/protobuf")
+ (commit (string-append "v" version))))
+ (file-name (git-file-name name version))
+ (sha256
+ (base32 "0aszb7cv8fq1m8akgd4kjyg5q7g5z9fdqnry6057ygq9r8r2yif2"))))
+ (build-system go-build-system)
+ (arguments
+ '(#:import-path "google.golang.org/protobuf"
+ ;; Source-only package
+ #:tests? #f
+ #:phases
+ (modify-phases %standard-phases
+ ;; Source-only package
+ (delete 'build))))
+ (native-inputs
+ (list go-github-com-google-go-cmp-cmp))
+ (home-page "https://google.golang.org/protobuf")
+ (synopsis "Go support for Protocol Buffers")
+ (description
+ "This project hosts the Go implementation for
+@url{https://developers.google.com/protocol-buffers,protocol buffers}, which is
+a language-neutral, platform-neutral, extensible mechanism for serializing
+structured data. The protocol buffer language is a language for specifying the
+schema for structured data. This schema is compiled into language specific
+bindings. This project provides both a tool to generate Go code for the
+protocol buffer language, and also the runtime implementation to handle
+serialization of messages in Go. See the
+@url{https://developers.google.com/protocol-buffers/docs/overview,protocol
+buffer developer guide} for more information about protocol buffers themselves.")
+ (license license:bsd-3)))