I was wondering whether it would be possible to use a Zig project to manage programs written in Zig. And it turns out you can!
Enter Zins
Thanks to the Zig build system the zins binary doesn’t have to do much. It creates a folder at {KnownFolders.data}/zins with a build.zig and a bare build.zig.zon.
When you add a package, it will just run zig fetch and then zig build. As long as the ./zig-out/bin folder is on your path, the binaries will be available to you.
How it works
The deployed build.zig file loops through each dependency, collects any .exe artifacts, and adds them to the root builder.
In future it it would be good to support multiple Zig versions and release builds.
git clone https://git.sr.ht/~deevus/zins
cd zins
zig build run -- install --package https://github.com/zigtools/zls
# Get bin-path using `zig build run -- bin-path` and add to `$PATH`
zls --version
Some caveats (since this is currently a PoC)
It’s limited to Zig 0.14.0 compatible projects
You can break the build by adding incompatible projects
There is currently no way to remove packages
I will continue working on it if there is interest in the project
A lot of Linux (and other *nix) users don’t like it when programs create random hidden directories in their $HOME directory. You should instead put this in the proper directory as directed by the XDG standard XDG Base Directory Specification
Well agree on being hidden is not very nice but creating a directory in to $HOME is something golang also doing, creating a go dir in your home and install stuff there with go install.
I don’t know the history of why Go does it like that, but it might be like Firefox that puts stuff in $HOME/.mozilla because it predates the xdg standard. In any case, the existence of the xdg base directory env variables means the user has told programs, knowingly or not, where they expect data to be stored and programs should not ignore that, unless they literally can’t remove it due to backwards compatibility. Since you’re presenting a new tool I expect it to follow the modern standards, so if I were interested in an zig version manager I would look elsewhere.
I’ve updated it to be at KnownFolders.data which on Linux will be $XDG_DATA_HOME if set.
/// The base directory relative to which user-specific data files should be written.
///
/// Windows: `%LOCALAPPDATA%\Temp`
/// MacOS default: `$HOME/Library/Application Support`
/// *nix default: `$HOME/.local/share`
/// XDG directory: `XDG_DATA_HOME`
///
/// XDG's definition of `XDG_DATA_HOME`: There is a set of preference ordered base directories
data,
Just a head’s up, there’s currently a bug in known_folders where it doesn’t check XDG_* environment variables on macOS unless explicitly configured to do so.
go std also sets ~/Library/Application Support or similar as the default location for config locations, whether its cli, tui, or gui, and ignores the user’s choice. Apple documentation explicitly forbids its use for files that might be accessed by the user. go is just not something you should look at for good practices.
the solution is simple – don’t create anything if it’s not already present, error out with a hint to specify the location explicitly via an option.
please, please don’t use ~/Library when you’re not interfacing with MacOS AppKit APIs. it’s only for application data that is never accessed by the user directly, ie, not via a graphical interface of an application. if it’s a text file you edit, it’s NOT the place to pick.
I’ve refrained from commenting, because I’m not sure i get the use case? Is there something more that this helps with than the running a git clone and then build install for the tool, adding it to my own ~/.local directory which is already on my PATH?
Without a README, I have no idea what it’s intended to do. Without a LICENSE, I’m not going to inspect the source code, which is proprietary, to find out.
No offense intended. You’re more likely to get useful feedback with those artifacts than without them.
I now understand the idea behind it. I think you’re in a situation where we’re the wrong audience for what you’ve built, because building and installing Zig binaries is something we all know how to do, and we probably trend toward having a preference for where to put them and so on.
I think you’re on to something though, especially if you solve everything on your short list: multiple Zig versions, incompatibility breakage, and removing projects as well as just adding them.
The most time consuming thing would be curation: to really make a smooth experience, zins should already know about neat binary Zig programs which users could install. Then you have something which Zig enthusiasts could tell our less enthusiastic friends about: download this program (and you’d want to distribute it in binary form), and Zig, and you can build and install all these programs written in Zig.
The main thing it needs to do is abstract over all the complexity, and right now it’s more like a centralized place for that complexity to live. It’s a proof of concept, so that’s just fine. I do like the idea!
Even if this forum isn’t the intended audience I would also say that I see a purpose here.
Currently I have a script that updates my Zig software based on the required version, switching/updating Zig compilers with zigup. anyzig or 100 other changes might simplify it, but still it would be completely unmanageable for someone who wants to do the equivalent of npm install for this case and move on with their life.
In that sense it could possibly (or especially) work as a kind of stop gap while Zig is still alpha and software is more likely to depend on different versions. I can see some appeal for people unfamiliar with the build system, but maybe also, for example, Linux package maintainers who don’t want to put mental gymnastics into managing Zig software. Maybe not the best example, package maintainers can be pretty fussy, but hopefully you get the point
