!UUqahLbShAYkkrXmKs:matrix.org

DevOS

39 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
In reply to @blaggacao:matrix.org
Most all fup importers come out of our feathers. At some points, ecplicit importing might be a tid more declarative / explicit, without being verbose (hopefully)
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:23:55
@mars:jupiterbroadcasting.commars* 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 opinion00:24:24
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid Arnold (blaggacao) Exporting by default was set as "sane" default since a lot of people don't care how (standardized) their front-yard looks to others. 00:28:20
@blaggacao:matrix.orgDavid Arnold (blaggacao)Opting out for inidividual modules / overlays might strike the right balance.00:28:59
@blaggacao:matrix.orgDavid Arnold (blaggacao) See __dontExport = true for overlays. 00:29:17
@mars:jupiterbroadcasting.commarsI guess the other thing with profiles is that it's assumed they're not intended for export00:29:26
@blaggacao:matrix.orgDavid Arnold (blaggacao)That is true.00:29:36
@mars:jupiterbroadcasting.commarsyeah i found that __dontExport attr in the source and I'm using it in a few places00:29:48
@blaggacao:matrix.orgDavid Arnold (blaggacao)Since they modify global state.00:29:51
@blaggacao:matrix.orgDavid Arnold (blaggacao)(at least when sticking with the soft guidlines)00:30:10
@blaggacao:matrix.orgDavid Arnold (blaggacao)(while modules would not, only the configuration soace, but not state)00:30:27
@blaggacao:matrix.orgDavid Arnold (blaggacao)* (while modules would not, only the configuration space, but not state)00:30:32
@blaggacao:matrix.orgDavid Arnold (blaggacao)We might be able to improve those contracts.00:31:09
@mars:jupiterbroadcasting.commars
In reply to @blaggacao:matrix.org
Since they modify global state.
yeah so this is one place where we could make an additional distinction I think of profiles as modules that don't declare new config options but profiles in that sense could still use, say, mkOverridable
00:31:11
@mars:jupiterbroadcasting.commars* yeah so this is one place where we could make an additional distinction I think of profiles as modules that don't declare new config options but profiles in that sense could still use, say, mkOverridable00:31:26
@mars:jupiterbroadcasting.commars* yeah so this is one place where we could make an additional distinction. I think of profiles as modules that don't declare new config options. but profiles in that sense could still use, say, mkOverridable00:31:37
@blaggacao:matrix.orgDavid Arnold (blaggacao) Can you have a look at: divnix/data-merge? 00:32:10
@blaggacao:matrix.orgDavid Arnold (blaggacao) The flake.nix. 00:32:18
@mars:jupiterbroadcasting.commarsand then they'd be safe to import in the sense that they couldn't make your nixos config not evaluate just because you imported them00:32:19
@blaggacao:matrix.orgDavid Arnold (blaggacao)It conveys part of my thinking about config mgt and complexity.00:32:34
@mars:jupiterbroadcasting.commarsi saw some messages about it above00:32:42
@blaggacao:matrix.orgDavid Arnold (blaggacao)(just for context, not saying no or yes) 😎00:32:48
@blaggacao:matrix.orgDavid Arnold (blaggacao)
In reply to @mars:jupiterbroadcasting.com
and then they'd be safe to import in the sense that they couldn't make your nixos config not evaluate just because you imported them
That is one aspect, but also importing something that can modify your state and is outside the boundary of your own repo seems hairy.
00:33:43
@blaggacao:matrix.orgDavid Arnold (blaggacao)I fear the explosion in complexity after a few layers. 😎00:34:42
@blaggacao:matrix.orgDavid Arnold (blaggacao)But, otoh, with nix people can do whatever they want, we can just empathixally encourage /discourage.00:35:14
@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

Show newer messages


Back to Room ListRoom Version: 6