I have another question - is there a way to make Zig package manager re-download dependencies?
I’ve been playing with my local lib + lib user project, and I have noticed you have to delete Zig global cache to make it update the dependency package.
I keep my .tar.gz locally, and I have noticed that you have to build the project that depends on it once, and then you can remove the .tar.gz file altogether.
Subsequent compilations use the cached version of the dependency package.
The purpose of the .hash field is to help verify that the contents of the package are exactly the same as when you first added the package using zig fetch --save, so whether the package exists in the global cache or needs to be downloaded anew shouldn’t really matter because only that exact revision with those exact file contents are allowed and any discrepancies will result in an error.
If you want to update a dependency to a different revision of the package, you can re-run zig fetch --save=<name> <url> to overwrite the entry for the dependency in build.zig.zon and update its hash to match the new version.
The only reason you would need to redownload the same revision of the same dependency is if you’ve somehow modified the package’s files in the global cache (which you generally should avoid unless you really know what you’re doing). In that case, run zig env, take note of the value of global_cache_dir, delete that directory tree and re-run zig build.
That’s exactly what I’ve been doing - deleting ~/.cache/zig over and over again.
Say, I’m developing a library, adding / modifying functionality, or fixing a bug. I’m using another project to check out my modifications. This project has its dependency url set to a local file, “file://…tar.gz”.
How do I force Zig package manager to re-ingest this file into its cache, without having to delete the cache?
If I don’t delete the cache, Zig won’t notice that the tar.gz file has changed, and just keeps using the cached version.
Try deleting the hash in build.zig.zon; my impression is that hash acts as a key to caching. build.zig.zon documentation about hash:
This field is the source of truth; packages do not come from a url; they come from a hash. url is just one of many possible mirrors for how to obtain a package matching this hash.
If you work on the lib and the application locally and have both of them available as source, then I would try to use .path in the build.zig.zon temporarily pointing it to the directory of the library. Instead of using .url and .hash.
When you are done working on it, you can just discard that temporary change towards using .path / not commit it.
You mean, replace the hash with an arbitrary (and incorrect, since we have to way to manually calculate it ATM, I believe) value?
Because you have to provide a value, and it must be of correct length, otherwise you’re going to get an error asking for a hash value.
If you use a path you must not have a hash.
If you have an url and you change it, you must change the hash also, otherwise zig believes that the hash is correct and loads the cached older version of url.
An empty “hash” is fine, zig will display the correct one after downloading the new “url”.