What building a Package Manager taught me

2 points

5 months ago

The Package manager from the official Zig source, meaning "zig fetch" was very annoying. I hated having to first fetch the project from a URL, and then copy code into the build.zig, and then have no intellisense, and just GUESS what I have to write, and what I do not have to write. It was chaos.

So I fixed it, by building my own package manager, zeP. https://github.com/XerWoho/zeP

It is a simple package manager and Zig version manager.

What did I learn, though? First off, building a package manager requires INTENSIVE planning. I am currently still on pre-release, which is where big changes are to be expected, but the number of big changes I have already made has made me realize that I have to stop programming and start thinking before committing to something.

For example, my executable was named zeP, which is an issue for Linux users. They always had to type zeP, with the capital P, which is simply annoying.

Before that, I had a Zig version manager in zeP, which, after installing a Zig version, or switching to a version, changed the path to the file of the executable. Meaning it added a new path on each install or switch.

~/zig-0.15.1/x86-windows/:~/zig-0.13.0/x86-windows:~/zig-....

Some can see how bloated a PATH variable can get after a while, and not only that, it is completely useless, because I check if the path is in the PATH variable, and if it is, I do not add it. Meaning that (for the example above), zig 0.13.0 will never be used again, because it gets overshadowed by 0.15.1. To fix this, I use symlinks. Only on main path; ~/.local/bin, and within that path, zig, which is getting symlinked across installs and switches.

Symlinks looked very good to me, since I found out how pnpm works. Pnpm works with symlinks, reducing installs, delays, and sizes, because there is a main folder which has ALL the files, and they are getting linked across projects. But, there was a catch. If you uninstall a package, it deletes the package in the main folder, meaning all the other projects which might have that package installed will have a dangling symlink.

Again, the solution was simple. A manifest.json. In there, we store all the packages, with their linked projects. This will check the linked projects, and if it the package has no linked projects, only then, will it delete the package; else, it will just unlink the project.

Needless to say, there were a lot of issues that required testing and using zeP myself. Only by using my own product, could I determine the issues other people might have with it. But some people also gave feedback, after which I fixed a few issues.

zeP has its own custom printer struct. It receives data, and then re-prints it, by clearing the entire screen, and then printing again. This was done, so I had stuff like progress bars, etc. However a user hated the fact, that zeP literally hijacked your entire screen. So now, zeP only clears its OWN lines, and leaves your other stuff alone.

Building a package manager does not only require testing on my side, but also community feedback.