Strategy for Zig packages

[<mcsinyx@disroot.org>]

Hello Guix,

Coming from Nix, I am considering switching to Guix in long term.
So far, my biggest gripe with nixpkgs culture, i.e. package vendoring,
seems to be well objected by Guix philosophy.

My current goal is to package software I use and/or maintain,
some of which are written in Zig.  Since Zig is still immature and
there is no consensus on downstream packaging, most user applications,
e.g. ncdu or mepo, resorted to only link with C ABI libraries.

Like Go, Zig code is meant to be statically compiled (it is possible
to write libraries with C ABI in Zig, though they fall under the former
category).  Since the language-specific package managers are still
experimental, some projects, e.g. river or blackshades, choose to vendor
libraries as version-control submodules and rely on relative imports.
Zig packages are specified (recursively) via

zig build-* --pkg-begin name path --pkg-end ...

so I suppose the Zig build system can wrap the command appropriately.

The third category is the software using a Zig package manager.
Dependency information should be retrievable from the manifests.

In case this has not been discussed before, what shall be the plan
for interdependent Zig packages in Guix?  On top of my head there are
a few options:

1. Wait until Zig reaches 1.0; it's too soon to decide now.
2. Work with Zig maintainers for a standard way to install
   Zig libraries as source code.  It could be something like
   ZIG_PKGS where package name is at $ZIG_PKGS/$name.zig,
   or a file containing all the mappings.
3. Wrap the zig command and feed it declared dependency information
   while waiting for standardization.

I would love to hear what Guix maintainers' thought on this issue.

All the bests,
McSinyx