GNU bug report logs - #54560
[PATCH 00/47] gnu: Add go-github-com-prometheus-prometheus.

Previous Next

Full log

View this message in rfc822 format

From: Leo Nikkilä <hello <at> lnikki.la>
To: "Maxime Devos" <maximedevos <at> telenet.be>, 54560 <at> debbugs.gnu.org
Subject: [bug#54560] [PATCH 01/47] gnu: Add go-google-golang-org-protobuf.
Date: Fri, 25 Mar 2022 22:55:34 +0000

> see go-github-com-golang-protobuf-proto.

I clarified the difference between github.com/golang/protobuf and google.golang.org/protobuf under 03/47.

Should <https://issues.guix.gnu.org/48259> be applied, the separate `-proto` and `-ptypes` packages could certainly be replaced by the merged package.

> What are ‘glob paths’ here?  They don't appear to be used anywhere else
> in Guix.  What's the problem with the default build phase?

There's no top-level package in google.golang.org/protobuf, instead the repository consists of individual packages which depend on each other.

Looking at (gnu packages golang), I see two ways this has been dealt with before: splitting each one into multiple Guix packages, or building all of the packages together in one Guix package.

There are many of these packages in the repository [0], and another list of "internal" packages [1]. (This listing doesn't cover all of them, some are deeper within the tree.) In order to use this library you'll need most of them, and splitting each one into a separate Guix package feels unnecessary.

There are examples in (gnu packages golang) where a single Guix package contains many Golang packages, e.g. go-github-com-blanu-dust, redefining build phases to reduce a list of packages instead.

However, the number of these packages makes this approach difficult. The list of internal packages is not considered public nor stable; these are added and removed between releases. Maintaining a list of these within Guix seems prone to breaking during the update process.

`go build' and others support wildcards [2], which are also used within build scripts of the library [3]. Since the upstream build makes use of these, I thought they would be fair game to build it.

However, due to how go-build-system correlates these import paths with directory paths, supporting wildcards in `#:import-path` directly would require further changes to the build system.

Adapting how go-github-com-blanu-dust and others call these build phases directly, I found this to be the simplest way to use the wildcard capability, and avoid having to maintain a list of the packages within Guix directly.

Happy to try out other approaches, this is just what I came up with earlier.

I should've also specified `wildcard' instead of `glob' when naming this.

[0]: https://github.com/protocolbuffers/protobuf-go#package-ind
[1]: https://github.com/protocolbuffers/protobuf-go/tree/v1.27.1/internal
[2]: https://pkg.go.dev/cmd/go#hdr-Package_lists_and_patterns
[3]: https://github.com/protocolbuffers/protobuf-go/blob/v1.27.1/integration_test.go#L118-L120

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.