!UUqahLbShAYkkrXmKs:matrix.org

DevOS

35 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.commarsthis is kinda the nature of the nixos module system though modules all modify one big config00:35:48
@blaggacao:matrix.orgDavid Arnold (blaggacao) Heheh, see divnix/data-merge. 00:36:17
@blaggacao:matrix.orgDavid Arnold (blaggacao)afk for a bot00:38:03
@mars:jupiterbroadcasting.commars

but yeah with profiles it seems like you're going for

stuff you might paste in a configuration.nix

and you can't paste two definitions of the same option in one configuration.nix

whereas modules that are potentially upstreamable are supposed to be safe to add to your imports

00:38:05
@mars:jupiterbroadcasting.commars* but yeah with profiles it seems like you're going for > stuff you might paste in a configuration.nix without much extra structure and you can't paste two definitions of the same option in one configuration.nix whereas modules that are potentially upstreamable are supposed to be safe to add to your imports00:38:52
@mars:jupiterbroadcasting.commars

so i get the basic idea

modules/ for stuff you should know about about the NixOS module system before writing

profiles/ for extremely simple bits of Nix code that are basically just dumb config that you don't really have to understand anything to write

suites is, I guess, just a shorthand for importing a bunch of profiles

00:40:59
@mars:jupiterbroadcasting.commars 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 00:45:55
@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

Show newer messages


Back to Room ListRoom Version: 6