Comments (21)
@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
from digga.
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.
from digga.
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).
from digga.
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.
from digga.
@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.
from digga.
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.
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?
from digga.
Just rebased server config on flake parts and used colmena to build hosts: https://gitlab.com/coffeetables/myrdd/-/merge_requests/10
from digga.
@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.
from digga.
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.
from 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.
from digga.
Wow! Haha, I've got a Frappe Bench "Cell" with devshell, nixos, packaging, etc code 😄
from digga.
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.
from digga.
@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.
from digga.
archive it. I moved to flake-parts. This is a good starting repo: https://github.com/srid/nixos-flake
from digga.
Maybe there are parts of digga that could live on as opt-in {devshell,flake,home,nixos}Module
s? 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).
from digga.
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.
from 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.
from digga.
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.
from digga.
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)
from digga.
Great, thanks to both of you!
from digga.
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.
from digga.
Related Issues (20)
- ci: workflow to build example hosts
- Onboarding documentation incomplete HOT 1
- [Documentation] Relationship between digga API and raw flake API/output
- How do I use the examples?
- `emacs-overlay` cause errors HOT 11
- Question - How do you make platform aware modules HOT 2
- Support customTestFor with multiple (different) nodes HOT 1
- bug report template: add example command to provide environment metadata HOT 1
- `groupByConfig`@`main` fails check due to insecure `python3.9-poetry-1.1.12` HOT 1
- use `.overlays.*` instead of `.overlay` HOT 2
- Inconsistent behaviour when accessing `self.lib` in different places
- Changes to user profiles are not applied upon rebuilding HOT 1
- Comparison to `divnix/std` & `divnix/hive` HOT 18
- Cannot login account when switch to devos config HOT 2
- nix-shell after following the quickstart guide returns an error
- digga tries to do something clever by loading all inputs' overlays, but fails HOT 9
- Clean Installation gives out error HOT 1
- Devos digga input needs update
- Infinite recursion encountered when using Stylix HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from digga.