Re: Go Package with multiple subpackage

[Nicolas Graves <ngraves@ngraves.fr>]

On 2024-09-22 13:21, Superfly Johnson wrote:

> The Azure SDK for Go 
> (https://github.com/Azure/azure-sdk-for-go/releases) has many 
> sub-packages within the same directory and the guix import method won't 
> work directly. I think the best solution for packaging the requirements 
> for rclone would be to make the sub-packages individual guix packages 
> using the url-fetch method instead of the git method. Each also depends 
> on several sub-packages.
>
> Thoughts?

There are possibilities for some build-systems to work on a workspace of
packages rather than a single package.

I remember I implemented that on a version of the rust-build-system
(never released, would take me quite some time to begin working on that
again), and the Node also considers working with packages.

When the design is good, you can even consider everything as a
workspace, since a package can be "a workspace of one package", and have
a single build-system being able to build all packages inside a repo,
much like submodules. In this case you could have a single guix package
with multiple outputs for each workspace's package. In my case I had for
instance a single pull of a repo with multiple crates such as
https://github.com/RustCrypto/elliptic-curves and multiple outputs, each
one for a single package.


I don't know if a modification of the go-build-system would be able to
handle that, but it seems that go also have a way to handle workspaces :
https://go.dev/blog/get-familiar-with-workspaces

I think it's a great direction to ease package update on Guix, since all
the complexity is handled in the build-system and upstream rather than
at the level of guix maintenance / user. And if a rust or node workspace
behaves poorly for some reason, then for this one we can still go back
to packages for this workspace. Although it's a big more tricky when
regarding things like searching packages, because it introduces a new
kind of "output-package". Maybe using something like

(define-public my-package
  (package
    (name ...)
    (source `(,workspace "output-name"))
    (build-system copy-build-system)
    (description ...)
    ...))

could be a solution to handle this.


Now to also answer on the issue raised by Denis, I agree that it's
better not to debundle when there are a lot of dependencies and when the
dependencies are not already packaged in Guix. Rationale is that there
is no space gain in debundling something that is not present elsewhere,
and indeed leaving certain things bundled might make it easier to build.
Also we can debundle partly based on what makes the more sense regarding
both space gains and maintainability : replace a few big library
dependencies but leave a few small ones not present elsewhere in Guix in
the source (ungoogled-chromium does that for instance).

-- 
Best regards,
Nicolas Graves