Once we have networking in the standard library (See #2007) the binaries shipped from ziglang.org/download could have a command to update to the latest one. The download page already has an auto-updated JSON version of the page.
This functionality would be disabled by default, so that package managers and source installations do not have the command, or perhaps the command exists but returns an error explaining to use the package manager. The CI builds would add a configuration option to enable this feature.
Until this is available, @marler8997's python script is handy.
This feature is not blocking on #2377. It would be perfectly reasonable to use blocking networking calls for this feature.
It's not important to ship this feature in any particular release cycle, as it's more for people who are using master branch.
One problem to solve is the fact that the tarballs have version information in the directory path, with the zig binary inside the versioned directory. So upon completion of the update, the directory name would be incorrect. Or if the update command renamed the directory, then the path to the zig binary would be different, possibly breaking a symlink.
Whether or not this feature should exist post-zig-1.0 is up for debate. However we're not at 1.0 yet and things change quickly. This might be a nice way to keep zig users up to date.
One problem to solve is the fact that the tarballs have version information in the directory path, with the zig binary inside the versioned directory. So upon completion of the update, the directory name would be incorrect. Or if the update command renamed the directory, then the path to the zig binary would be different, possibly breaking a symlink.
I like that the tarball directory is versioned because it lets you
With these advantages, the only problem that needs solving is how you make zig accessible in your PATH. The solution my python script uses is making a symlink in a PATH directory to point to the latest executable in the versioned directory, and on windows the same thing can be done using a batch script instead of a symlink. At the same time, the versioned directories are still available and any versioned compiler can be called explicitly if desired.
# use the latest zig compiler
zig
# use a specific version
~/bin/zig-linux-x86_64-0.4.0+7d4a0cfe/zig
Can there be a hardcoded link that redirects to the latest tarball?
e.g. status 302: https://ziglang.org/builds/zig-master.tar.xz => https://ziglang.org/builds/zig-0.4.0+9daf0140.tar.xz
Can there be a hardcoded link that redirects to the latest tarball?
No, due to limitations of s3: #1046
Having a link to the latest could also encourage misuse of the server. Rather than downloading the name of the latest version and checking whether or not you already have the latest compiler, you're always downloading the full compiler each time even if you're already on the latest.
I suggest that zig update is always built into the executable, but can be disabled by adding a special file to the packaged distribution. I could continue using official builds in snaps, and just toss in an extra file during the packaging process. Ex: echo "Zig was installed with the snap package manager. Use 'snap refresh zig' to update." > zig_update_override.txt
To expand on that idea. The file could contain the instructions to perform the update as well.
Oh sorry @jayschwa you already included that idea. I read too quickly from my phone.
I came here wondering if there was a Zig Version Manager (like there is for Go with GVM, and Nodejs, etc). Just some shell scripts for managing installations of Zig and installing new ones.
One could definitely be created with just a few lines of code as a JSON version of the all of the builds is available here. I'm not sure if it should be included in zig, though, or if it should be a separate project.
shell script which uses only curl/tar and ~/.local
https://gist.github.com/nektro/3c704a2e117b3e33b576ee5d6f7f7107
Most helpful comment
https://gist.github.com/MasterQ32/1f27081d8a7dd109fc290bd6729d97a8