The package manager is great, the “problem” is due to Zig being so young and constantly changing, which means the available libraries people are developing are also constantly changing (or being left behind). In my projects I target the latest point release in order to have some measure of stability, and some libraries do the same, but most target the current nightly. The end result is a minefield of builds breaking every time I try to update for a code fix or (god forbid) switch to the next Zig compiler version.
This has lead me in recent projects to start avoiding use of libraries, and to just “write it myself” whenever reasonable. It isn’t always reasonable, and that brings a lot of stress while I debate how much I need the library versus how much I’m going to be fighting to keep it working. If the library is simple enough (i.e. a math library, or API wrapper) I’ll sometimes absorb the source files directly into my project, taking responsibility to maintain them for the life of the project. For others, the library’s size or complexity leads me to just reject it outright and I add to my to-do list to learn to write that functionality myself.
Is anyone else experiencing this? How do you handle it? Is there anything we can do as library writers to minimize this result on users?
This worked for well-maintained libraries like http.zig, but did not completely eliminate the problem. Then I experienced the opposite problem, I need to upgrade Zig, but libraries have not been upgraded, so I started vendoring them using git-subtree.
As much as I hate it, I’m trying to avoid even dependency on std at this point. I’m not completely there yet, but I’m slowly moving towards that. Either I’m using my own code, or a library has history of not breaking API too often. The paradox is that I’m writing libraries that I want people to use, but I just accept that I primarily do them for myself.
Part of the problem is that everyhing Zig-related is too young and people are experimenting. It will take time until things settle. I’m trying to get my own libraries to the point, where I can do a stable release and not change the API much after that.
My approach is to fork the libraries I depend on and participate as directly as possible in maintaining the libraries I rely on. I am happy to be able to directly contribute to the supply chain I depend on.
That’s a good point… So far I’ve only forked libraries as part of submitting PRs. Using a fork full-time as a shield against breaking changes makes a lot of sense.
I’ve also experienced this (I used to rely on mach-freetype a couple years ago), and my solution was to just make use of Zig’s C interop and use C libraries instead (harfbuzz, freetype, miniaudio, stb), or write it myself when I really want the advantages of Zig.
Though I also have a bit of an odd project, with some deviations from the intended design of Zig which would also add friction in other ways if I were to operate with libraries.
If you want to strengthen the eco-system then I think it would be best to collaborate with the maintainer of the library, a project that has many collaborators is also a project that others will find easier to use or switch to.