!UUqahLbShAYkkrXmKs:matrix.org

DevOS

36 Members
Seeking help and geeking out together on https://github.com/divnix/devos & https://github.com/divnix/digga10 Servers

Load older messages


SenderMessageTime
20 Oct 2021
@mars:jupiterbroadcasting.commars

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
@pachumicchu:myrdd.infoPacman99
In reply to @mars:jupiterbroadcasting.com
i don't love modules/, though, because potentially a digga user will have modules for NixOS, home-manager, nix-darwin, and (I just learned this also has modules today) devshell— which are all different module systems
Devos 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
@mars:jupiterbroadcasting.commars
In reply to @pachumicchu:myrdd.info
Devos 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.
I can tell! if you don't have a top-level nixos attr passed to digga.mkFlake, it chokes ;)
00:55:32
@pachumicchu:myrdd.infoPacman99
In reply to @mars:jupiterbroadcasting.com

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

I 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
@mars:jupiterbroadcasting.commars
In reply to @pachumicchu:myrdd.info
Devos 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.
wym groupByConfig? is that an existing template?
00:56:56
@pachumicchu:myrdd.infoPacman99
In reply to @mars:jupiterbroadcasting.com
I can tell! if you don't have a top-level nixos attr passed to digga.mkFlake, it chokes ;)
Uhhh 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
@pachumicchu:myrdd.infoPacman99I wonder if there's anything else in nixos we rely on...00:58:21
@pachumicchu:myrdd.infoPacman99
In reply to @mars:jupiterbroadcasting.com
wym groupByConfig? is that an existing template?
Yeah its one of the examples in digga
00:58:52
@pachumicchu:myrdd.infoPacman99In the nix-darwin PR, a top-level hostDefaults was proposed, I think this is a good argument for that01:00:02
@mars:jupiterbroadcasting.commarsI was just looking at that, was about to bring it up!01:00:25
@mars:jupiterbroadcasting.commarswanted to review the discussion there first01:00:33
@mars:jupiterbroadcasting.commars 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
@mars:jupiterbroadcasting.commars

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
@mars:jupiterbroadcasting.commars

basically just like:

if you wanna define any packages or modules (whether for HM or Nix-Darwin or NixOS), put them here1
if you wanna define any hosts capable of being managed through Nix (whether Nix-Darwin or NixOS), put them here2
if you wanna define any per-user home-manager configurations not necessarily bound to any particular hosts, put them here3
if you don't need any of those, feel free to leave them undefined

01:09:34
@mars:jupiterbroadcasting.commarsseems like that's the direction digga is going. is that right?01:10:25
@mars:jupiterbroadcasting.commars
In reply to @pachumicchu:myrdd.info
In the nix-darwin PR, a top-level hostDefaults was proposed, I think this is a good argument for that

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

01:16:09
@mars:jupiterbroadcasting.commars* 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
@pachumicchu:myrdd.infoPacman99Channels are shared already its just the default channel that isn't01:26:30
@pachumicchu:myrdd.infoPacman99But generally I think I agree with you on other points01:26:46
@pachumicchu:myrdd.infoPacman99I'm starting to think a top-level hostDefaults might be warranted01:27:09
@mars:jupiterbroadcasting.commarsok cool. thanks for the correction and for thinking through this with me01:27:29
@pachumicchu:myrdd.infoPacman99We should make a github issue or discussion for this, if you would like to get that started01:28:35
@mars:jupiterbroadcasting.commarschannels 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
@pachumicchu:myrdd.infoPacman99Exactly and there are semantics like sharedOverlays and overlay dependencies that channels help with01:29:25
@pachumicchu:myrdd.infoPacman99
In reply to @pachumicchu:myrdd.info
We should make a github issue or discussion for this, if you would like to get that started
I 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
@mars:jupiterbroadcasting.commarshow many users are there atm?01:31:33
@timdeh:matrix.org@timdeh:matrix.orgWe've toyed around with starting an RFC process in the past. For now we could either start a github discussion or issue01:31:32
@timdeh:matrix.org@timdeh:matrix.orgwell 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 out01:32:41
@timdeh:matrix.org@timdeh:matrix.orgwe'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
@mars:jupiterbroadcasting.commars 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

Show newer messages


Back to Room ListRoom Version: 6