Fetching a project without that project's dependencies

Help
1

I am extending my project to verify downloads using minisign.

I only need a part from lib.zig from the zig-minisign package, so I could copy that and strip what I don’t need.

What I first tried though, is adding the dependency to my my build.zig.zon ( using zig fetch --save ...) and build.zig

const minizign = b.dependency("minizign", .{ .target = target, .optimize = optimize });

exe.root_module.addImport("minizign", minizign.module("minizign"));

And I can use pub elements from zig-minizign’s lib.zig in my program.

What I checked for was if zig-minisign had dependencies in its build.zig.zon, and it does, as it uses clap for command-line parsing. Although that package is only needed by zig-minisign when creating its standalone utility (which I am not doing), this package got downloaded in my zig-pkg directory.

How can I prevent this unnecessary download of clap (both for me and for all users of my package)? Can I put something in my build.zig.zon file that prevents loading of sub-packages? Or does this require an update of the build.zig.zon that is in the zig-minisign module?

2

This.

It would require that the zig-minisign package marks clap as a lazy dependency .lazy = true but that also requires significant rework of its build.zig, and ultimately I don’t think that the end result would be good.

It makes sense for minisign to be both a library and a CLI tool in one package, and I also can understand your interest in minimizing downloads if you’re working on something that is used a lot in CI, for example.

My recommendation is to vendor the code that you need for minisign in this case.

3 Likes
3

I don’t think it requires significant rework as it already has condition to not build the CLI if target is freestanding for example. Could have a build option to not bring the CLI binary + use lazy dep indeed.

4

zf has a with_tui option to disable the tui (which depends on vaxis) when only the fuzzy matching module is needed. Ghostty is using it and it seems to be working fine:

// From ghostty
if (b.lazyDependency("zf", .{
    .target = target,
    .optimize = optimize,
    .with_tui = false, // this removes the dependency on vaxis
})) |dep| {
    step.root_module.addImport("zf", dep.module("zf"));
}

I think that’s similar to what is wanted with zig-minisign? It wasn’t too complicated

1 Like
5

In harha I have comma separated list of optional modules to include https://github.com/sorvi-platform/harha/blob/master/build.zig#L50 Obivously not that interesting as there is only one such module at the moment :smiley:

6

When I added zf to my project to try, that indeed didn’t pull in vaxis. But unfortunately the building of the minizign exeutable is not dependent on an option (but resolved_target.os.tag == .freestanding). I’ll ping the developer to see if making it an option is an option.

Of course I did not read zf’s README, and certainly not the library docs it points to, and tried zig fetch --save https://github.com/natecraddock/zf/archive/refs/tags/0.10.2.tar.gz, which results in an error because "zf" is not an enum. That was bit confusing until I realiased ghostty was using a newer version than the latest you published under releases. As they say in my country of residence: “Wer lesen kann ist klar im vorteil.”

7

ah good info, I didn’t look at the build script. I still think in this case vendoring is the better solution though.

2 Likes
8

Yeah might be, it’s single standalone file after all.

9

Once one of these get implemented, they also could be used to deal with situations where you only depend on one (or a few files):

But if vendoring turns your project into one that has no external dependencies, that might make your project simpler to use and more resilient to future changes.

While I like the package manager, there is the risk of ending up with having the urls and hashes to dependencies that are no longer hosted or reachable via that url and then it could be difficult to find out whether there is another url serving that same source code.

Maybe we should have something like an internet archive for zig packages :wink:
I guess if the torrent for zig packages gets implemented, people could just keep a collection of zig packages locally and the urls would remain valid as long as somebody seeds it.

1 Like