Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

legacy packages are unnecessarily fetched #23051

Closed
andrewrk opened this issue Mar 3, 2025 · 3 comments
Closed

legacy packages are unnecessarily fetched #23051

andrewrk opened this issue Mar 3, 2025 · 3 comments
Labels
bug Observed behavior contradicts documented or intended behavior zig build system std.Build, the build runner, `zig build` subcommand, package management
Milestone

Comments

@andrewrk
Copy link
Member

andrewrk commented Mar 3, 2025

Zig Version

0.14.0-dev.3451+d8d2aa9af

Steps to Reproduce and Observed Behavior

  1. delete global zig cache
  2. zig build in a project that uses legacy hash format (e.g. 1220e97357cc39f4f9f053c763f3ec1623e0c7f3999f185746f2bd9bf9b5c5551392)
  3. observe that global zig cache now has something like N-V-__8AAJCtGQSh2-Qbxpqs91AmpxWIEhmOomX7nKxk3Lkc instead (new hash format)
  4. zig build --system ~/.cache/zig/p
  5. observe that it fails with "package not found" errors for all legacy hash formats used

Expected Behavior

Expected cache hit, no network usage.

Suggested workaround: upgrade to new hash format
Alternate workaround: use zig-0.13.0 to zig fetch legacy packages

I have no plans to solve this bug. Problem will solve itself as projects upgrade to new hash format.

@andrewrk andrewrk added bug Observed behavior contradicts documented or intended behavior zig build system std.Build, the build runner, `zig build` subcommand, package management labels Mar 3, 2025
@andrewrk andrewrk added this to the 0.14.0 milestone Mar 3, 2025
@andrewrk andrewrk closed this as not planned Won't fix, can't repro, duplicate, stale Mar 3, 2025
@andrewrk andrewrk marked this as a duplicate of #23060 Mar 3, 2025
@linusg
Copy link
Collaborator

linusg commented Mar 5, 2025

One instance where this is problematic is integrating with C libraries that have no knowledge of the Zig build system and completely lack a build.zig.zon, thus being treated as "legacy packages". The All Your Codebase project has a bunch of those, personally I'm affected via my icu4zig project, a wrapper around ICU4X's C bindings which it fetches via the build system and then sets up the include path by pointing into the dependency.

As a result of this issue a repeated zig build leads to the upstream package being fetched every single time, and the proposed solution is not applicable - I can't ask ICU4X to add a manifest just to work around this. The same behavior can be observed in much more lightweight packages like https://github.com/allyourcodebase/zlib which fetches upstream zlib.

I do not wish to go back to git submodules or vendoring for this use case :^)

@GalaxyShard
Copy link
Contributor

One instance where this is problematic is integrating with C libraries that have no knowledge of the Zig build system and completely lack a build.zig.zon, thus being treated as "legacy packages". The All Your Codebase project has a bunch of those

It appears C projects without build.zig.zon can still be given an updated hash following the new format (and thus no longer being a legacy package), just run zig fetch and update the hashes like below:

$ zig fetch https://github.com/linusg/build.crab/archive/8710b559525e17584e2ab39545a3d449e9311409.tar.gz
build_crab-0.1.7-4WwLHQ6XAADhcLKJW965zlYROScnnxHwx6J28KgoyVEG
$ zig fetch https://github.com/unicode-org/icu4x/archive/ee2814ea79125da5f849454cb670fc33a19eac69.tar.gz
N-V-__8AAEa0_Ana_oGLMvcFQ8utJMxsjgdYyHmBAU40RGti

Since the C dependencies have no build.zig.zon at all, they don't need to be updated to fit the new format, just the dependent needs to update the hash.

The repositories in All Your Codebase would have to update all of their hashes as well in order to support the new format.

@linusg
Copy link
Collaborator

linusg commented Mar 5, 2025

oh, there's a solution hiding in plain sight - thanks for pointing that out! I was convinced I updated all of my deps with new hashes, looks like I missed one 😅

@linusg linusg marked this as a duplicate of #23130 Mar 7, 2025
SimonLSchlee pushed a commit to SimonLSchlee/raylib that referenced this issue Mar 8, 2025
the old package hash format has a known bug, that causes unnecessary
fetching: ziglang/zig#23051

this is avoided by using the new hash format
@linusg linusg marked this as a duplicate of #23159 Mar 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Observed behavior contradicts documented or intended behavior zig build system std.Build, the build runner, `zig build` subcommand, package management
Projects
None yet
Development

No branches or pull requests

3 participants