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