legacy packages are unnecessarily fetched

[andrewrk]

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.

[linusg]

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 :^)

[linusg]

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 😅