DevOS | 36 Members | |
| Seeking help and geeking out together on https://github.com/divnix/devos & https://github.com/divnix/digga | 10 Servers |
| Sender | Message | Time |
|---|---|---|
| 20 Oct 2021 | ||
| and even if they all (for now?) have the same kinds of modules, they have different stuff in them. extra care has to be taken (if it's even possible) for a whatever-module.nix file to work for both NixOS and nix-darwin or whatever | 00:48:01 | |
In reply to @mars:jupiterbroadcasting.comDevos was mostly made with a focus on nixos. So modules/ is meant for nixos. I think that's the best sane default. But we could always make the groupByConfig structure the default. | 00:54:16 | |
In reply to @pachumicchu:myrdd.infoI can tell! if you don't have a top-level nixos attr passed to digga.mkFlake, it chokes ;) | 00:55:32 | |
In reply to @mars:jupiterbroadcasting.comI think there has been work to make this possible, but it requires a lot of groundwork to work with various init systems and configuration methods | 00:55:35 | |
In reply to @pachumicchu:myrdd.infowym groupByConfig? is that an existing template? | 00:56:56 | |
In reply to @mars:jupiterbroadcasting.comUhhh I think that is kind of a bug. I would prefer if that didn't happen, but we rely on nixos.hostDefaults.channelName | 00:57:57 | |
| I wonder if there's anything else in nixos we rely on... | 00:58:21 | |
In reply to @mars:jupiterbroadcasting.comYeah its one of the examples in digga | 00:58:52 | |
| In the nix-darwin PR, a top-level hostDefaults was proposed, I think this is a good argument for that | 01:00:02 | |
| I was just looking at that, was about to bring it up! | 01:00:25 | |
| wanted to review the discussion there first | 01:00:33 | |
I think it's great if devos is NixOS focused. I like how the pkgs/ dir is structured to mimic Nixpkgs and the file declaring the overlay is like Nixpkgs' top-level/all-packages.nix | 01:02:38 | |
| but for me I'm trying to figure out if digga would be nice to use to define a generic Nix code repo seems like with the nix-darwin related PR it might be more or less there? | 01:03:42 | |
| basically just like:
| 01:09:34 | |
| seems like that's the direction digga is going. is that right? | 01:10:25 | |
In reply to @pachumicchu:myrdd.info ok, looking again at that PR:I think being able to share channels between all consumers of nixpkgs is a good idea, so I like a top-level also for sharing module code between module systems, digga doesn't need to be clever you can tell digga that a module is compatible with a given module ecosystem by symlinking it into the appropriate dir, if you don't want multiple copies of it | 01:16:09 | |
| * ok, looking again at that PR: -- I think being able to share channels between all consumers of nixpkgs is a good idea, so I like a top-level `hostDefaults` also for sharing module code between module systems, digga doesn't need to be clever you can tell digga that a module is compatible with a given module ecosystem by symlinking it into the appropriate dir, if you don't want multiple copies of it does that seem too clunky? | 01:16:30 | |
| Channels are shared already its just the default channel that isn't | 01:26:30 | |
| But generally I think I agree with you on other points | 01:26:46 | |
| I'm starting to think a top-level hostDefaults might be warranted | 01:27:09 | |
| ok cool. thanks for the correction and for thinking through this with me | 01:27:29 | |
| We should make a github issue or discussion for this, if you would like to get that started | 01:28:35 | |
| channels here is terminology inherited from fup, right? and what it means is collections of packages that are similar to nixpkgs in structure (they expect the same arguments when you import them, they can be modified through the overlays interface) | 01:28:44 | |
| Exactly and there are semantics like sharedOverlays and overlay dependencies that channels help with | 01:29:25 | |
In reply to @pachumicchu:myrdd.infoI think we should make a practice of doing this for any major api change, sort of like an unofficial RFC system(maybe make something official in the future?) | 01:30:13 | |
| how many users are there atm? | 01:31:33 | |
| We've toyed around with starting an RFC process in the past. For now we could either start a github discussion or issue | 01:31:32 | |
| well we don't keep any sort of telemetry on users so there is no way to say with absolute confidence, but if github stars are any indication, we can say about 552 people have at least tried it out | 01:32:41 | |
| we've also had something like an unofficial competition with: https://github.com/hlissner/dotfiles I've always intended to try that repo out one day and see if there were any insights that could be gleaned since clearly a lot of people like it, I just ended up not having the time yet 😅 | 01:34:38 | |
nix flake info and nix flake show seem not to work on any of the examples in the fup repo anymore, with a message about the relative path being outside the parent's store path (it is not) | 03:26:31 | |