Declarative packaging is weird, but honestly, I see the appeal. Especially coming from a Linux lens, where y'all's ecosystem is so chaotic and asynchronous- as in, efforts aren't done in the same tree by different people at different times with optional collaboration, which leaves lots of duplicated efforts and fracturing. It seems like everyone's development efforts are done without any real useful coherence.

For context, this is coming from an OpenBSD user and ports maintainer's perspective. I s'pose OpenBSD has a much smaller community that can coordinate on packages and such, which is why this might be less useful on such a system.

That said, declarative packaging is useful beyond that. If someone did get a Nix or Guix package system cleanly working on BSD- Like that one NixBSD project- I think it would still be useful from a programmer's perspective. Unfortunately, at least for Guix (my favored of the two), it's still very Linux-centric and hardly portable. IDK about Nix, as I have less experience with it. I just fired up an Alpine VM under OpenBSD's vmm(4) to play with a contribution adding flakes support to my exfetch project from a NixOS user, to test their PR to facilitate easier development on Nix{,OS}.

Unfortunately, my habits have gotten so used to traditional Makefiles and simple package management that I never bothered exploring unique alternatives. As my stubborn-ass sees it, the ports tree and binary package handle deps fine. My opinion on this has fortunately changed thanks to that contributor. But even then, from a full-system package management lens, I don't use that many ports/packages, 'cause my base system is already pretty functional OOTB, so IDK if I'd want it managing everything on my system.

For me, Linux's async design is a big turn-off, as it leads to inconsistencies and less integration. I'm saying I prefer a project that cohesively develops both the kernel and basic functionality in the userland with the same tree, same dev team, same programming style- leaving the rest up to the user to do with as they please. This approach minimizes the headache and frustration of building or maintaining a package orchestra (distro) on top of a kernel with little hit in your freedom to choose what you want. Linux is pretty much the only ecosystem that has this asynchronous kernel and userland situation, and I don't think there's ever gonna be a perfect workaround to the inherent problems if you use regular package management on it. Solutions like Guix and Nix solve uniquely Linux-y problems that no other OS vendor is affected by, to my knowledge.

Not to say Nix or Guix aren't without merit on other systems, however. I feel their prowess really shows in versioned software development. I had a brief foray with Guix-SD a few years back and really liked it, or my really recent dive into Nix stuff with another dev on my exfetch project showed me where Nix would shine in the software dev space in making a consistent ecosystem devs/contributors can work with. Nix has been ported to OpenBSD, so I'm curious how building a software development system w/ it would look like.

I feel declarative packaging is a brilliant hack for Linux's chaotic system config, but for configuring tightly integrated systems like OpenBSD, it's mostly a solution in search of a problem. I'd also be excited for what comes of declarative style software development on the *BSDs. IMHO