any feedback or feature idea/request is welcome! thanks
ha and I also have a question: currently I prioritize using the community mirrors to download zig; does that make sense or should I prioritize the official download instead so the download speed is more consistent?
concidentally we are are being ddossed right now (or some vibecoded ai crawler is misbehaving, hard to tell the two cases apart nowadays) so prioritizing mirrors would give your users a better experience
Imo one thing most Zig version manager woukd profit from is enhanced shell completion. Since, in a best case scenario, you won’t use these commands too often, fast an informative completion is really helpful.
Before 0.16.0 was released I found myself often running zig any list-installed and then manually copying a version number into the next command prompt…
Interesting idea, unfortunately the bash system for doing auto completions is quite annoying. I could add a zim completion command and so you can add a completion script that just calls to it.
I see thanks. I did follow the community mirrors instructions they were very helpful.
I wonder if there is a good way to check the download speed of the mirrors so it can pick a not-too-slow one. Maybe a ping and checking the latency would be fine enough.
For getting the list of possible version numbers you can do something similar like I do for getting the build steps, project options and system integrations ( https://codeberg.org/anthon/zigclc/src/branch/main/_ext/zig_dynamic_build_steps.yaml ), in your case you would have to
create a restriction that calls the command to get the list of versions in some form, parse the output and and calling sc.normal() for all the results. That will actually filter out those result that don’t match the partial result the user typed for you. ( i.e. if 0.1<TAB> was input it will filter out 0.9.0 for you and let through 0.15.2 and 0.16.0 etc.) You may have to cache the parse result if getting the list is slow.
I think it would be nice to have a command that lists what versions you have currently installed, akin to bob, that way if someone is not sure if they have a particular version installed, they can check before fetching it again.
Somewhat off-topic, but it’s maybe worth taking a look at Mise, for inspiration if nothing else.
It doesn’t meet the “written in Zig” requirement, but it also doesn’t fall into most of the pitfalls of shim-based solutions either. I’ve been pretty happy using it to manage my Zig versions so far (it uses mirrors by default!)
When active on a shell, it checks your cwd (and its parents) for a mise.toml file, and references it to perform actions like add folders to $PATH (this is how it performs directory-dependent executable versioning). This updates every time the terminal prompts.
It also has a built-in command to quickly install and use specific versions of zig, zls, python, node, and several others either globally or in the current directory, as well as providing shims that use the program’s cwd if you need a static path.
That’s true, and I wasn’t saying it was a feature that is absolutely necessary, but it is already a fairly established command that a lot of version managers have. I also like having a consistent interface, so if I want to check, I don’t have to remember where zig is installed or run a different command. It’s really just a nice-to-have.
We are deep, deep, deep into mise now. Mise is incredible and improving rapidly. I predict that soon it will be the standard for tooling on dev machines. Possibly production as well. Mise replaces asdf, direnv, dotenv, make, and zillions of homebrew 1-5 line scripts. We use it for go, npm, python, ruby, rust, & zig across all projects now.
Dev/vps machines can also use mise to easily install tools like age, bat, gitleaks, rg, watchexec, and many others.
Not totally sold on mise tasks yet, so we include just = "latest". Just is great too, not quite ready to switch yet.
It still uses toml as the configuration file format.
However, I’ve generally found that unless I’m doing complicated things with with it (which I try not to do and generally don’t need), I barely need to use the less readable parts of the toml spec. They also have a bunch of CLI commands that will modify the config for you, as long as you’re doing something common (ex: mise use zig@0.16.0 will create or modify a mise.toml file that adds Zig 0.16 to $PATH inside the current working directory).
When I do need something more complicated, I’ve been implementing the functionality as mise plugins instead, so I can script it in Lua rather than declare it in toml. So far, I’ve only done this to expose system libraries/headers installed via linuxbrew.