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.