Zig package management

Help
1

Hello,

I should know this but I don’t.

How do I collect the up to date versions of these archive hashes.

.dependencies = .{
    .chameleon = .{
        .url = "https://github.com/tr1ckydev/chameleon/archive/3d7fdd61598edecacd2c53c5ecff76a79abb8661.tar.gz", <--- this tar.gz
        .hash = "1220018d65a2105db410846019d23fd9966ace9f5cacc2fdec5c1ad4275009b94b70", <--- this hash
    },
},

I want to use this in a project I’m working on, but I think their README.md .zon is out of date.

I can’t figure out where this archive url is.

Sorry simple stuff lol

2

so, are you looking to update the hash or the URL ?

The hash can conveniently be updated in the .zon file with

zig fetch https://github.com/tr1ckydev/chameleon/archive/3d7fdd61598edecacd2c53c5ecff76a79abb8661.tar.gz --save
2 Likes
3

I want to update this .zon file to master.

Which would imply changing both I believe.

I want to pull down a tar of the up to date source code.

4

not sure if there is a (semi-)“automatic” option to update the URL, would be nice to know / have :slight_smile:

As for the URLs, it’s

https://github.com/[author]/[package-name]/archive/[commit-or-tag].tar.gz

most of the time I guess. At least for github. IFAIK, it’s the same for Codeberg repos, for instance.

Note that at the moment, you could also use a branch (main, master etc.) instead of a tag or commit, which might be good for experimentation on the bleeding edge, but a shot to the foot in terms of stability / reliability. See discussion below.

5

Maybe try using the url to the main branch
https://github.com/<author>/<package>/archive/refs/heads/main.tar.gz

1 Like
6

main works. Thanks all.

7

Relevant issue: add tooling to deal with build.zig dependency trees · Issue #14288 · ziglang/zig · GitHub

The idea here is that zig package management tooling will have different strategies to check for updates based on the URL.

6 Likes
8

No please don’t use branches for the urls, the moment somebody pushes an update to that branch the content gets a new hash and now your build suddenly starts failing.
Use either tags or the commits directly, because with those the hash will continue to stay the same.

Take a look at create a commit specific archive download link

1 Like
9

That makes sense. Why doesn’t gh have a .tar.gz button. I saw the zip.

I’ll follow your guide. Thanks.

10

Right, branches better be reserved for experiments :wink: I think this can actually be useful, for example if you want to compare two branches of the same library.

11

I guess when you do things that stay on your machine, then it doesn’t matter what url you pick, or maybe even if you are just working on some application that not many care about.

But getting in the habit of using unreliable urls should be avoided, because the moment some library that uses other libraries uses some branch urls, you get a bad situation where in some unknown point in time all your previously well defined packages and all packages that depend on those get broken and can’t be built anymore, just because somebody somewhere pushed a new commit to an old branch.

Personally I think it would be a good idea, if future tooling would reject branch urls, or have some way to add the info which commit that branch referred to at the time the hash was calculated.

An additional problem is that there is nothing in your project history telling you which commit that branch pointed to, so when it breaks, you now are in the bad situation having to search for a commit that works.

I think those are bad situations to be confronted with, which is why I am against using branches as urls.

Until there is extra tooling to make branches usable, I think they should be avoided generally for urls, I also think you should avoid dependencies that use branch urls in their build.zig.zon.

1 Like
12

That’s totally reasonable. Ultimately, we shouldn’t have to copy-paste URLs to the zon file in the first place, as add tooling to deal with build.zig dependency trees · Issue #14288 · ziglang/zig · GitHub lines out.

2 Likes