#Ziggy - A version manager for Zig + Project starter written in typescript using the bun runtime.

1 messages · Page 1 of 1 (latest)

dapper cosmos
#

Hello guys I would like to introduce you to my new project which I had a personal need for managing zig installations, with minimal system mutation. I ended up creating ziggy which is a CLI + TUI that helps you manage multiple zig versions (as available on ziglang.org/download) and also comes with it's own init command that gives you a barebones zig project that just compiles and is mostly empty. Why? Because when I bootstrapped using zig init, it was too much code for my taste, so ziggy init actually gives you two template options. The standard one and the bare-bones one.

Here's the app itself (https://github.com/weezy20/ziggy). You can use bun to install it from npm as well (https://www.npmjs.com/package/@weezy20/ziggy)

It requires bun to run and the reason I chose bun is because it's a widely used tool that many non-zig systems can easily be bootstrapped with.
You can run it without installation as well using bunx.

Overall it works much like zvm (written in go). It has a directory that houses your zig installations and it provides you with an env file that you can add to your shell profile so that ziggy bins are available on your system path.

Here's the barebones template repository used in ziggy init (https://github.com/weezy20/zig-app-template)

npm
@weezy20/ziggy

A fast, easy to use, Zig programming language installer and version manager powered by Bun. Latest version: 1.1.0, last published: a few seconds ago. Start using @weezy20/ziggy in your project by running npm i @weezy20/ziggy. There are no other projects in the npm registry using @weezy20/ziggy.

GitHub
GitHub - weezy20/zig-app-template: Lean zig app template. If you're...

Lean zig app template. If you're using ziggy you can bootstrap your project using this template with ziggy init - weezy20/zig-app-template

mild creek
#

you also don't appear to be validating the signature, or even the checksum of the tarballs you're downloading

#

your color output also doesn't appear to check that it's actually outputting to a TTY, which means any kind of automation using this will result in logs with ansi escapes in them

dapper cosmos
#

Ah those are nice suggestions. I will include signature and checksum validation in the next version.

How would I check if my color output is going to a TTY? I might need to look it up

mild creek
#

tty.isatty(1)

#

oh, seems like tty.isatty(Bun.stdout) works too, that's a bit nicer

dapper cosmos
#

@mild creek why would it benefit to use a community mirror than ziglang?

mild creek
#

benefits zsf by reducing their bandwidth costs, benefits you/your users by increasing reliability and potentially speed

dapper cosmos
#

Gotcha. Makese sense but I'm having a hard time finding a decent sig verification library. Got any ideas? The ones i found are in C or Zig

mild creek
#

you can pinch mlugg's impl, it's MIT licensed

#

it uses libsodium for the actual cryptography stuff

dapper cosmos
#

thanks I'll use this then

dapper cosmos
#

Files are signed with minisign using this public key:

RWSGOq2NVecA2UPNdBUZykf1CCb147pkmdtYxgb3Ti+JO/wCYvhbAb/U

is this expected to ever change? If yes I can include a mechanism to look it up but it's going to be some bit of code as the key is not available at https://ziglang.org/download/index.json

mild creek
dapper cosmos
#

Getting download info for Zig master...
Trying mirror 1/3: zig.florent.dev
⚠ Download failed from zig.florent.dev: Error: HTTP error! status: 404
Trying mirror 2/3: zig.squirl.dev

Verifying download authenticity...
⚠ Signature verification failed for zig.squirl.dev, trying next mirror...
Trying mirror 3/3: pkg.machengine.org
⚠ Download failed from pkg.machengine.org: Error: HTTP error! status: 404
Downloading from official source: ziglang.org

from my experience implementing this pkg.machengine.org: always passes the minisig verification but zig.squirl.dev, doesn't.. I'm not sure what's the problem

mild creek
#

it's possible something got broken and I'm just not aware of it cuz mlugg's check mirrors action isn't working right now, but I haven't changed anything so that'd be kinda weird

dapper cosmos
#

Ah nevermind there was some issue with my code

#

it's working now

dapper cosmos
#

Hey squirl, I reimplemented this in Rust, with community mirrors and minisign/shasum verification as the foundation for any installation.

Please have a look and let me know your thoughts!

github.com/weezy20/zv

mild creek
#

a zig version manager written in rust is kinda hilarious ngl

mild creek
#

u have a bunch of error messages in src/app/network/download.rs that say ur gonna do stuff that u never actually do - eg. 429 says it'll delay before retrying, which, firstly, makes no sense because 429 is local to one mirror so if ur trying a different one there's no reason to delay, and secondly, u don't actually do. that error is eventually handled here and i don't see a delay anywhere

#

there also seems to be a bunch of code for handling mirror ranking?? which is never even used cuz u set all the ranks to 1

#

there's no real reason to rank mirrors anyway, the downloads aren't large enough for mirror speed to be a major issue, and it's better to spread the load across multiple mirrors rather than just hammering the ones that are fastest

#

they won't be fastest for long if u do that 🙃

#

ur retry logic also just re-randomizes the list every time - u should randomize the list once at the start, then iterate over it for retries; that way u never try the same mirror twice

#

also u don't appear to verify the minisign comment - gotta check the filename matches up to prevent downgrade attacks

#

frankly i'm amazed how much code u've managed to write just for mirror handling. for reference, my implementation is 30 lines of shell, and mlugg's is about 60 lines of js

dapper cosmos
# mild creek there also seems to be a bunch of code for handling mirror ranking?? which is ne...

that's a todo for future as I realized that I could implement that code during zv sync to try various mirrors and rank them based on speed as during testing i found some mirrors perform 10x worse than some other mirrors (though it's not sufficient to de-rank them). The ranks are there specifically to lower their bias during next random selection. I agree, iterating over the list is much better.

dapper cosmos
dapper cosmos
#

Yeah i think I kinda intentionally left it out becz it was getting messier with retries and I figured changing the mirror is much simpler. Maybe I'll just change the function name do download file standalone