Repository navigation
a zig subcommand that fetches remote dependencies so that subsequent zig build executions are guaranteed to not attempt network access #14280
Description
Activity
- addedenhancementSolving this issue will likely involve adding new logic or components to the codebase.Solving this issue will likely involve adding new logic or components to the codebase.contributor friendlyThis issue is limited in scope and/or knowledge of Zig internals.This issue is limited in scope and/or knowledge of Zig internals.zig build systemstd.Build, the build runner, `zig build` subcommand, package managementstd.Build, the build runner, `zig build` subcommand, package management
on Jan 12, 2023 Until the last sentence I thought there will be two separate commands:
zig fetchfor just downloading, andzig build --fetchfor downloading+building.zig builddoes everything, while avoiding redundant work if possible, such as accessing the network. See also #14283.I like the elixir approach where you have to run
mix deps.getat least once before you can compile. It makes it more explicit. Havingzig builddo everything is convenient, but it makes it further frombuildand would make it more complex.Reacted by Riccardo Binetti, Max Milton and Simon A. Nielsen KnightsReacted by Komu Wairagu and Gamer-KoldWould this also mean that Zig would get hooks for sandboxing?
Does Zig intend to solve the use case of sneaky programs doing network access?If not: Should, and if yes, what tools should the user be given to prevent this?
This includes techniques like removing dynamic linker, adjusting runtime path, on supporting Kernels bpf sandboxing [we had bindings in std.x.net], which are also relevant for reproducible builds.Reacted by Max MiltonPerhaps the command could be
zig pkg fetchsuch thatpkgwould be the sub-command for all package related commands which are not directly building.Reacted by Simon A. Nielsen Knights and Ian Johnson
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsFetching
Extracted from #14265.
I can think of two possibilities:
This is straightforward to implement; it would run this code, without actually running the build_runner:
zig/src/main.zig
Lines 4080 to 4126 in 7cb2f92
One thing to consider would be a slightly higher level abstraction of subcommand which would additionally build and install dev dependencies. For example, if there were a binary tool that should be available, it should get installed. But that can be a follow-up issue.
I think I like the
zig build --fetchoption better becausezig fetchsounds like it might download a URL directly, which is not an outrageous idea considering the "Zig as Dependency Zero" motto.