The power hack and complexity of Package Manager in Zig
Ed Yu (@edyu on Github and
@edyu on Twitter)
Jun.27.2023
Introduction
Zi...
For further actions, you may consider blocking this person and/or reporting abuse
this is a nice informative article. I'd suggest though that instead of putting a random hash to find the correct hash, you omit the hash field entirely:
this gives the same effect without any potential errors.
also good to mention is that you can use
.path
instead of.url
for local dependencies on master branch, and it's just that one line change :) (it also doesnt need a hash)Wow a built-in package manager is what I'm looking for. Thanks Ed for sharing.
Besides, I'm thinking whether it's a good idea to use an URL to package instead of searching for a tag in Git commit history. That was what I learned from go mod package management. It removes the needs to ask package provider maintain their tarballs, and gets rid of our own hash verification logic because Git has provided it. It seems Zigmod also does a similar way.
Did we get a chance to consider whether this is also a feasible approach for zon?
Hi Fuzhou,
Thanks for the comment. Andrew replied to a post I made about this blog in ziggit and he's thinking about removing the hash just for the reason you mentioned. I however wouldn't know when it would be made into the Zig system.
As for commit history, there is a way to point to the commit such as
but I haven't tested it with the latest zig. Is this what you meant?
Thanks Ed. Actually what I'm looking for is something like below.
My first goal is we eliminate the needs of maintaining tarballs. For source code dependency scenario, tarball does not work well on a common scenario, that we want to do close peer testing with upstream dependency on an unstable branch. Even we have strong devops support today, many small projects do not publish non-stable source code tarballs. Even for large projects, they don't always publish as we want. In this case, developers seems have no choice but fallback to checkout source code, then re-package it ourselves. Thus, forcing the use of tarballs on dependencies does not sound like a ideal idea.
Meanwhile, hash validation is necessary for sure, while I prefer we avoid developers or library users maintaining it. Git hash should be able to do this trick.
Btw, I somehow has a task to evaluate zigmod/zpm earlier. So far it seems existing non-official package managers support downloading source code from Git (just requires an additional index server). The difference is it seems they don't actively honor versions/tags/commits. And seems they don't validate (not 100% sure, to be double confirmed). I was thinking they are in a lack of complete git support in Zig, while I like their design decision of depending on source code repo.
I'm not very sure why a built-in tool, instead, depends on tarballs. This looks like we are taking one step back (sorry for saying this). It could be totally understandable if this is a temporary solution, while I'm wondering the final direction.
Or kindly suggest/correct me if I miss anything.
I actually agree. I would highly recommend that you go to the zig github page and file an issue. The core team is usually very supportive of good idea especially if you have real-world use-case that contradicts how they think about the issue. I do think it's a temporary solution as we've been battling the TLS bug (if it indeed is the problem) for a while. I still have problems getting any tarball to download properly without segfault on the first try.
My goal for this article is more of "what it is" not "what it should be" so people like you can point the project to the right direction. :)
Let me know when you do and I'll help getting Andrew to look at it if and when I can get his attention.
Has this happened yet?
Filing an issue on Github? Not yet. :(. I'm busy recently to catch up Halloween release for my game project. Thanks for @edyu 's suggestion. I will find a chance to make it happen!
Hey @edyu , I'm about to create an issue on Github.com. However, it seems I can't find a proper category. For now it allows creating issues for Autodoc Issue, Bug Report, and Error Message Improvement. I don't think they fit our discussion. There are Language Proposal and Question. Unfortunately they point to Wiki page.
Could you suggest a place that we can bring our topic to community?
You can use bug report. As for discussion, you can use zigget.dev but eventually it would still go back to GitHub.
Thanks! Seems the idea is already under tracking in Github. github.com/ziglang/zig/issues/14298 . Let's track from here.
Nice introduction to zon, thanks for sharing. I was wondering if there's already the possibilty to use a local path instead of a git url for a package? For like when you want to work on your own library in parallel to a project which is using it as a package via zon.
Here's one way:
Ah nice, didn't thought about spinning up a local http server for this, thx :)
Most people run
zig build
a first time to get the Zig-compatible sha256 hash of the tar.gz file (you get the actual hash as an error)If you wanna do it yourself, here's quick Python script I made: gist.github.com/cryptocode/7bf963c...
404 unfortunatelly, might be a private gist 😇
Can you try again? Others seems to be able to access it.
gist.github.com/cryptocode/7bf963c...
Thanks for checking again, works. Maybe I wasn't logged in or sth.
A follow-up Part 2.
This might be a stupid question but, is there any way to use .zon file other than for build? like store custom data or something, and load them from a zig file.
Thanks for your article.
It helps me to tune up as a sharable package a module I wrote:
jailop.github.io/ziggraph/