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
Thanks Ed. Actually what I'm looking for is something like below.
// For stable builds - I used my own project as example
.url = "https://github.com/fuzhouch/lpath"
.version = "v0.1.0"
// or for non-stable builds
.url = "https://github.com/fuzhouch/lpath"
.version = "4e7d4c8" // It point to https://github.com/fuzhouch/lpath/commit/4e7d4c8cb7a7948114fb1f4e738176dc1f30f6e3
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.
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.
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?
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.