TL;DR: The project is over, and I'm tired of archlinux

Supac - a past long due

I guess it is finally time I sunset the project. It was long due, and I was really, really tired of the antics of different package managers, all of which behave differently, in really annoying ways.

Most importantly, the idea was to provide a declarative frontend to package managers. This started way back with pacdef.

I was nervous to dip my toes into nixos, yet, at the same time, wanted a declarative frontend for my packages because I kept forgetting what I installed and why I installed it.

I was tired. Really, really tired of manually managing packages on my system.

If you notice my website, you'll note that I have a conf link right in the beginning. That was an era on me using emacs. I was fully convinced that literate programming is the best thing to exist on this planet. I was dumb as fuck.¹

In any case, I was of the view that package management and dotfile management are two different things. Some might argue they still are, but I won't digress into that discussion.

And thus came about the repeated contributions to pacdef. I wanted to make it a one stop solution for my system management needs. Did I tell you I was dumb as fuck?

Eventually, there was another contributor ripytide, who joined me in making pacdef better. He had some... bold ideas. And I... just went along with the flow. Big mistake, as it turns out.

The original creator of pacdef went AWOL, and we did not have push or merge permissions. So we decided to fork it. We added repeated improvements and kept working on it till we had a nice little CLI. And then came the rift...

I was of the view that it should be able to declaratively specify language toolchains in addition to just packages². Ripy disagreed, because it made the codebase complex and I kind of had to hack my way around toml to get it working, which upset him. Fair enough I guess.

Regardless, an even greater split was on the fact that I wanted scripting abilities in addition to being able to work my way through things. I disliked the way TOML config felt so... dry. It was practically bland, since you could not define anything at all to be followed through, and doing anything to the internal data representation effectively meant changing TOML spec, trashing any and every sense of backwards compatibility.

It was around the same time I started getting involved in the nushell project as well, in particular, the new-nu-parser. I was fresh out of a compilers course, and wanted to prove that I can actually write decent compilers on my own.

I decided to start my own project from scratch, removing all the legacy debt, and going all in on nushell integration. The reason was simple. I was a nushell contributor, and nushell allowed for debugging as you went, and far greater scripting.

This allowed users to build much better abstractions on their own rather than us having to upstream everything into the core logic. But most importantly, it let the code be significantly extensible, since passing a nushell record around and only fetching the fields we wanted meant that we can add new fields anytime without breaking existing fields, in turn, preserving existing behaviour too.

This would have been an amazing idea. I was extremely bullish on this. I even set up some complicated dotfiles of my own to get this working.

But then I realised I was fighting a battle not worth fighting.

Where supac is right now, and what holds for its future

Right now, a bunch of things work. But I was increasingly getting tired of fighting the package managers. It was clear that they didn't want to cooperate. More importantly, I wanted it to be rather seamless and save on bandwidth and time wherever possible. That it itself was a nightmare.

See, the thing is that arch does not have one repository. It has many. If you go on to add additional repositories, it becomes an absolute pain in the ass to get all that working cohesively. Add in package groups and meta-packages, and you're done for. I really, really wish I was joking.

Thing is, it's not like nixpkgs doesn't have all these features. Except, they do it at a higher level, letting nix the evaluator take care of generating derivations while having these super-packages or meta-packages defined at the nix the language level, thus not having any of these issues like I do.

Instead, arch decided to just shove in all of this at the package level and bully humans like me, people who want declarativity and scriptability over their packages.

More importantly, I absolutely hate having to shell out to the actual package managers. It looks extremely distasteful. I want more native interop.

alpm.rs, the rust bindings for libalpm, do exist, but they go out of sync so hard that it basically often renders your package cache unusable. It's a misery, if I'm being honest.

And then, add the same behaviour, but compounded by cargo-binstall and cargo-install-update. Sure, these tools work and work well, but integrating them by CLI and shelling out to them feels extremely icky. I'd rather not do that.

In the end however, I feel like it's probably not worth it to integrate all of them natively.

Apart from that, I spent a while on nixos. Sure the language has one too many papercuts. But honestly, it's fine for writing config of your system. You can, for the most part, LLM your way through it, or just read the docs, of which there are sufficient. nix.ee is another wonderful resource, right there.

Nix opened my eyes in another way. Managing toolchains was a bad idea. It is better off being spec'd in the project itself. Most major projects do that and it works wonderfully.

And then, there's integration. I used nushell because it lets you seemlessly convert things between different formats, and its records look familiar enough to most eyes that they can just use it normally. However, I realised that reaching a level of integration of home-manager and alike is practically impossible (again, because it's done on a scripting level and nobody's there to put in the effort).

So what's it, finally?

I don't know! Perhaps I'll continue to work on it. Perhaps I won't. Truth be told, I have zero clue on it. I really just want to get good package management. I think nix will cut it for now.

Even though the language sucks absolute ass.

---

1. As an aside, I no longer hold that view. It should be fully possible for programming languages to be expressive and eloquent enough to describe the operations that one would want. See the articles by Alexis King and the generic idea of making error states unrepresentable. Extensibility is a different issue, and that comes much later.↩︎

2. A decision which I've come to regret since. It was because I almost always needed the latest and the greatest rustup for my own personal project, and never ever pinned the toolchain. Stupid, I know.↩︎