| 20 Oct 2021 |
 David Arnold (blaggacao) | In reply to @mars:jupiterbroadcasting.com
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 lib?
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? Part 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.org
So it is an organizational distinction? No difference in the invariants? Not 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
internal overlays don't get exposed in outputs.overlays. a way to present a nice & tidy frontyard to your neoghbours... oh!
non-exported might be a clearer name, if a clunkier one. hidden also makes sense to me in the same sense as hidden files on Unix: kept slightly out of your way for tidiness sake. but non-exported is probably still clearer
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.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 | * 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 |
| David 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 |
| David Arnold (blaggacao) | Opting out for inidividual modules / overlays might strike the right balance. | 00:28:59 |
| David Arnold (blaggacao) | See __dontExport = true for overlays. | 00:29:17 |
| mars | I guess the other thing with profiles is that it's assumed they're not intended for export | 00:29:26 |
| David Arnold (blaggacao) | That is true. | 00:29:36 |
| mars | yeah i found that __dontExport attr in the source and I'm using it in a few places | 00:29:48 |
| David Arnold (blaggacao) | Since they modify global state. | 00:29:51 |
| David Arnold (blaggacao) | (at least when sticking with the soft guidlines) | 00:30:10 |
| David Arnold (blaggacao) | (while modules would not, only the configuration soace, but not state) | 00:30:27 |
| David Arnold (blaggacao) | * (while modules would not, only the configuration space, but not state) | 00:30:32 |
| David Arnold (blaggacao) | We might be able to improve those contracts. | 00:31:09 |
| mars | 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 | * 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:26 |
| mars | * 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:37 |
| David Arnold (blaggacao) | Can you have a look at: divnix/data-merge? | 00:32:10 |
| David Arnold (blaggacao) | The flake.nix. | 00:32:18 |
| mars | 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 | 00:32:19 |
| David Arnold (blaggacao) | It conveys part of my thinking about config mgt and complexity. | 00:32:34 |
| mars | i saw some messages about it above | 00:32:42 |
| David Arnold (blaggacao) | (just for context, not saying no or yes) 😎 | 00:32:48 |
| David 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 |
| David Arnold (blaggacao) | I fear the explosion in complexity after a few layers. 😎 | 00:34:42 |
| David Arnold (blaggacao) | But, otoh, with nix people can do whatever they want, we can just empathixally encourage /discourage. | 00:35:14 |
