Ending digga
Pacman99 opened this issue · 21 comments
I would be hard pressed to recommend digga to anyone anymore. It has become increasingly difficult to maintain and has a number of bugs hidden behind its API. I believe many of the original users have switched to std or other frameworks and I myself am thinking of re-basing my repos on flake parts and removing dependence on digga.
I'm happy with what we've done through this repo, it was a really fun and effective project that helped me (and I hope others) understand and get started with flakes. I believe it has inspired other efforts in projects in this same space. If we had more manpower, maybe we could refactor and improve digga to be better, but I don't see that happening anytime soon. I wish we could keep it going, but I think pretending this project is still alive is a lie and harmful to anyone planning to use digga.
I think the best path forward is to add a message in the README linking here and eventually archive the repo. But I don't want to make this decision without general community support.
For anyone wanting to transition out of digga, I think either std, flake.parts, or flake-utils-plus covers most of the exporting related features digga provides. And those projects are simpler in scope and have better designed APIs.
Digga's unique features are auto-exporting, building hosts and home configurations, and automatic host testing.
Auto-exporting is riddled with bugs (ex: #496) and in retrospect I think it was a mistake.
Building configurations can just be done manually with nixosSystem and deploy-rs functions without too much work. I think std is adding this feature in the future and I could see flake.parts improving their nixosConfigurations module, or maybe some external module that improves nixosConfigurations and deploy exports.
I've haven't used the testing features much, but I do know it makes a lot of assumptions that end up making them fail often, so it's probably better to manually define tests anyways.
I've gone back and forth on whether to respond to this. I don't want anyone to feel pressured on whether the project continues.
I use digga through the devos example to manage 16 systems, mostly servers, a couple of laptops, a desktop and a darwin host. This provies me a consistent base environment and wildly different configurations on different hosts. I'm not sure that I would have done as much with Nix if it wasn't for digga and devos. Managing multiple systems seemed quite daunting before I found devos. Devos provided enough structure for me to really get into it.
When devos was merged in / demoted to an example, it was quite painful for me. While I had been using it fairly successfully, I had very little knowledge of how it worked. Working through that transition, vastly increased my knowledge but, and perhaps this is the problem, I don't have any idea how to replace the parts of digga that I use. It has worked well enough for me that I've never had to really dig in and understand it all. Since I've never had to dig in, I didn't turn into a contributor.
There are also parts of digga that I simply don't use. I've never used checks, in fact they currently break my ability to do nix flake show. The only exports that I've used are the host configurations and the dev shell. I manage deploying through nixos-rebuild ... --flake .#host --target-host ...
I'm sad at the prospective of digga being retired but, maybe it is time to move on.
Just rebased server config on flake parts and used colmena to build hosts: https://gitlab.com/coffeetables/myrdd/-/merge_requests/10
@btobolaski I think one of the issues of digga is that we had so many ideas and wanted to implement all of them, but they all got implemented poorly. We spent time thinking about each idea and its implementation, but when we put them together it was hard to work out a good api to integrate them all. And maybe the reason is that such an api doesn't exist.
I'm excited about some of the more focused efforts like haumea, flake-parts, and colmena that focus on one goal (ie auto importing, building hosts, and exporting things). Luckily they all seem to work together well and I used them all in the PR I linked above.
archive it. I moved to flake-parts. This is a good starting repo: https://github.com/srid/nixos-flake
Maybe there are parts of digga that could live on as opt-in {devshell,flake,home,nixos}Modules? In addition to the ones that already exist.
Inspired by this thread, I too migrated to flake-parts, haumea, etc. This included writing some flake modules to replicate certain features from digga, like deploy-rs profile and portable Home Manager user definition generation. Would be happy to contribute these back to digga (though perhaps attempting to upstream them to deploy-rs, etc. is the better approach).
I was thinking of making some features of digga into a flake.parts module, but anything I could think of seemed like they belong in an upstream repo instead of digga.
I've been using digga for a while now. Tried switching to hive / std / flake-parts today, hated it. It's way more involved than this process should be. For me, digga is something I can throw configs at (in an organized manner, with modules/profiles/suites) and say, "here, figure it out."
It has become increasingly difficult to maintain and has a number of bugs hidden behind its API.
I would love to clean up the repository and API. I think there's still a lot of life left in this project.
@bobbbay have you looked at https://github.com/srid/nixos-flake ? this is a sane alternative that uses the more widely-accepted flake-parts, and also a good starting template. no hidden strings.
Yes, I saw it in the chat. It looks great, but I don't see it supporting the std / hive format, + I'm not even sure how you would set up deployment through colemena or deploy-rs on that. I like my abstractions, and digga has provided the right ones for me. And, I imagine, many others.
Hive / std seems to be a more general framework, while digga cares more about shell-, home-, and hosts- environments, so digga's api is designed around these three cores, which is very reasonable and user-friendly, especially in The two concepts proposed for composability: Suites and Profiles are very easy to understand
And digga also considers multi-user scenarios very well, and shares the same concept with multiple hosts, which is a very elegant architectural design.
Maybe there are parts of digga that could live on as opt-in {devshell,flake,home,nixos}Modules
That's a very good idea
I was thinking of making some features of digga into a flake.parts module, but anything I could think of seemed like they belong in an upstream repo instead of digga.
If the upstream can achieve the best, then digga only needs to combine them and tell everyone what is the best practice.
only another better digga can beat a digga.
I may add that Standard is meant for the Software Delivery Life Cycle, and Hive tries to accumulate more general purpose best practices around Module System Applications (i.e. NixOS, WSL, Darwin, Home Manager, etc).
Hive currently optimizes only for plugging into upstream tooling via hive.collect in a so-called "layer of soil" (welcome to the world of obscure names 😄 — I'm not an esoteric, but boring names are, well, boring and beautiful, but hard to remember and discern).
The three abstractions Modules, Profiles, Suites are implementable without getting really involved for each Module System Application by declaring a blockType.{function,anything}. Configurations have a conceptually stricter typing and are already in place.
Some glue modules help make these different Module System Applications better work together, but nothing exciting and no magic. The onus of such magic would be indeed on the upstream maintainers of those applications.
@blaggacao are there any basic examples of applying hive available online? I get that there's a lack of documentation due to the fast-changing nature of that project, but I think a few basic examples of how one could combine std + hive (+ parts) would help in migrating away from digga, if that's what's intended with this project.
Probably it's time for a golden path, no promises, though. Hive development cadence is considerably slower than Standard's because I don't change my system config all too often and another project using it is private, unfortunately. But maybe I get to open source it in the context of a frappe/frappe development and deployment environment one day.
@bobbbay I won't say that my configuration is the best way to use hive, but I have various different systems managed by hive (WSL, nix-darwin, NixOS aarch64, and x86-64 hosts), with Cirrus CI that builds every host configuration and Github Actions to update flake and nvfetcher sources. I did not use any complicated structures, just basic std + haumea thingies. There are some places to improve (like introduce some kind of system generators to make less duplication in code etc), but other then that it works just fine
You can check it out here: https://github.com/truelecter/hive
haumea thingies
Good that you mention haumea. In my opinion that's a real leap in the way we can define our profiles. Hive + Haumea are as much an alliteration as they are a really good match.
(Paisano [base for Standard & Hive] may even be eventually reworked to leverage haumea)
Great, thanks to both of you!
Probably it's time for a golden path, no promises, though. Hive development cadence is considerably slower than Standard's because I don't change my system config all too often and another project using it is private, unfortunately. But maybe I get to open source it in the context of a
frappe/frappedevelopment and deployment environment one day.
Sorry for the off-topic but is this https://github.com/frappe/frappe? We just finalized and deployed https://git.pub.solar/axeman/erpnext-nix as a flake / nixos module. Maybe this is interesting for you?
Back on topic, thank you for sharing your configs here and for the helpful feedback. We are looking into flake-parts currently, but still wondering how to best use it with deploy-rs and something similar to digga's channels.
Wow! Haha, I've got a Frappe Bench "Cell" with devshell, nixos, packaging, etc code 😄
I have added a deprecation notice to the readme because I am not using digga and am unable to maintain it. If anyone wants to keep working on this project I'm happy to hand over commit access. Please email me if you are interested I don't check github notifications very often (email address is in my profile).