 | DevOS | 33 Members |
| Seeking help and geeking out together on https://github.com/divnix/devos & https://github.com/divnix/digga | 10 Servers |
| DevOS | 33 Members |
| Seeking help and geeking out together on https://github.com/divnix/devos & https://github.com/divnix/digga | 10 Servers |
| Sender | Message | Time |
|---|---|---|
| 19 Oct 2021 | ||
 mars | In reply to @ultranix:matrix.org deploy-rs doesn't have to do anything; it's just deploying a NixOS host flake digga uses fup's hostDefaults.modules to add home-manager to all the host flakes | 16:54:23 |
| mars | the part where it passes the modules arg to home-manager is in fup-adapter.nix | 16:56:44 |
| mars | did i miss anything? | 17:00:11 |
| mars | what does setting at the top of | 17:24:24 |
 ultranix | adds hem to /etc/nix/nix.conf | 17:28:20 |
| ultranix | * adds them to /etc/nix/nix.conf | 17:28:26 |
| ultranix | flakes wont be enabled otherwise | 17:28:42 |
| mars | I guess I'm just wondering why the top-level thing is being used instead of having that live down inside a NixOS module somewhere | 17:30:40 |
| mars | if it's just a style thing, that's cool I'm just trying to learn from the template | 17:35:33 |
| ultranix | i really liked nixus because it was 100% nix | 17:37:33 |
| mars | ok, looks like most of the interesting stuff in digga might be in its importers | 18:37:42 |
| mars | I'm a little fuzzy on the distinction between internal, external, and in-house overlays as mentioned in the source comment next to importOverlays | 18:38:28 |
| mars | looks like there's something similar going on for hosts | 18:43:03 |
| mars | feels weird that we're using import machinery in flake.nix right next to the thing fup gives us to avoid importing modules ourselves | 18:43:48 |
| mars | In reply to @mars:jupiterbroadcasting.comwhich, slightly surprisingly, are also exporters! hm | 22:28:12 |
| mars | trying to get a feel for why devos is so eager to export I partially get it and I partially don't like how come devos users end up exporting an output is that just for historical reasons, because folks may be using the devos repo on github as a library in their flakes rather than as a template? | 22:54:39 |
| mars | or is it just an example and it happens to give you devos' lib like just another example of the many kinds of outputs you might want your flake to have, and a lib for other flakes to use is one of them? | 23:26:47 |
 David Arnold (blaggacao) | In reply to @mars:jupiterbroadcasting.comSuites are host classes. It's probably most useful if you're managing a Univerity with DevOS. But behold, you can use a few suites for yourself, too, to get in the mood. Roughly, that's it. | 23:53:54 |
 tomberek | So it is an organizational distinction? No difference in the invariants? | 23:55:04 |
| David Arnold (blaggacao) | In reply to @mars:jupiterbroadcasting.comObsolete declarativeness. 😆 You can call it a fetish. | 23:55:18 |
| David Arnold (blaggacao) | In reply to @ultranix:matrix.orgDeploy-rs has this long running watcher process on the target. Maybe nixus was nix + bash though? | 23:56:51 |
| David Arnold (blaggacao) | In reply to @mars:jupiterbroadcasting.cominternal overlays don't get exposed in outputs.overlays. a way to present a nice & tidy frontyard to your neoghbours... | 23:58:11 |
| David Arnold (blaggacao) | In reply to @mars:jupiterbroadcasting.comMost all fup importers come out of our feathers. At some points, ecplicit importing might be a tid more declarative / explicit, without being verbose (hopefully) | 23:59:29 |
| 20 Oct 2021 | ||
| David Arnold (blaggacao) | In reply to @mars:jupiterbroadcasting.comPart of DevOS foundations is the sharing story, ehich is still underexploited. This is why exports are view through the glasses of your potential downstream re-users. | 00:00:45 |
| David Arnold (blaggacao) | In reply to @tomberek:matrix.orgNot primarily, suites are just a good way to aggregate profiles flatly , eg. teacher / student. But the same can be done with profiles themselves. A flat profile space + one level of aggregation (that NOT also holds config) might help keep things a little bit tidier. | 00:03:14 |
| mars | In reply to @blaggacao:matrix.org oh!
but I definitely see why one would not want to export every overlay you use in a channel | 00:03:23 |
| mars | In reply to @blaggacao:matrix.orgto me, the desire to export a module or overlay isn't something that can be inferred just from the fact that it's declared in my repo rather than in an input source I do like that there's a convenient way to export all of the modules or whatever from a directory I think I need to use it for a while to develop a real opinion | 00:23:55 |
| mars | * to me, the desire to export a module or overlay isn't something that can be inferred just from the fact that it's declared in my repo rather than in an input source. I do like that there's a convenient way to export all of the modules or whatever from a directory. I think I need to use it for a while to develop a real opinion | 00:24:24 |
| David Arnold (blaggacao) | Yeah, this is very arguable. The way everything is exported, though is very granular. But maybe we can come up with a better overall sharing model. | 00:26:30 |
| David Arnold (blaggacao) | Granularity gives power to the downstream user and lift's requirements to "curate" upstream. It's one particular generational contract. | 00:27:26 |