phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
orivej has joined #nixos-dev
__monty__ has joined #nixos-dev
niksnut has joined #nixos-dev
emily has joined #nixos-dev
<srhb>
I want to add something like `types.jsonnable = oneOf [ (listOf jsonnable) (attrsOf jsonnable) (nullOr (oneOf [ bool int float str ])) ]`. We're using ad-hoc methods for json merging with lots of shallow-merge all over the place, and this seems to me to get rid of an entire class of those bugs by just imposing module semanticsf in the obvious way. Anyone foresee any issues with that?
<edef>
that sounds interesting
<edef>
do we have some examples of where this is happening?
<edef>
i'm guessing there are also some places where module merging semantics are not appropriate
<srhb>
I think every module that has a config file that's written out as builtins.toJSON of types.attrs is susceptible to users hitting this -- I've seen it a lot at work recently.
<srhb>
You may be right that module merging semantics is wrong in some cases, but I feel like it's usually less wrong than `foo.bar.baz = 42;` silently nuking `bar`
<edef>
i'd rather it conflict, probably?
<srhb>
That would also be valid, but then you need some more complicated ergonomics for "adding baz to bar"
<srhb>
This just makes the usual NixOS logic apply to JSON config structures.
<srhb>
Which I feel is intuitive, at least, but maybe that's Stockholm syndrome :-P
<srhb>
The alternative solution is probably making all these types functions over the final attr fixpoint and forcing the user to merge manually. That doesn't sound very nice to me.
<srhb>
I think my main grief is actually the existence of types.attrs. It's almost always wrong.
<srhb>
types.mergingAttrs is what people tend to think they're getting, but it's not.
<srhb>
Of course, the RFC infinisil wrote up already touches on exactly this.. :)
<srhb>
(And the need for lazyAttrsOf which I totally neglected mentioning. :-P)
mmlb has quit [Ping timeout: 276 seconds]
justanotheruser has joined #nixos-dev
orivej has quit [Ping timeout: 250 seconds]
<aanderse>
lol @ srhb comment on Stockholm syndrome
<aanderse>
that's always the concern, right? we've all drank the nix kool aid and don't realize how insane we are ;-)
<dtz>
Haha yep! And crazy is in the eye of the beholder or something. But naturally I very much agree with that statement, gchristensen :). Or wouldn't be here!
<MichaelRaskin>
Even if functional programming is irrelevant as a tool, it allows you to filter for people who have to had changed their approach to writing code at some point in life
<aanderse>
MichaelRaskin: you vaguely mention your opinions on nixos once in a long while. I'm still curious what the better option is.
<gchristensen>
you should see MichaelRaskin's init system ...
<MichaelRaskin>
What init system?
<MichaelRaskin>
There is jus a bog-standard trivially-reconfigured
<MichaelRaskin>
sinit
<gchristensen>
ohI thought it was lisp-based, or is that something else?
<dtz>
Lmao clever <3
<clever>
:D
<MichaelRaskin>
There is a ton of Lisp, just on another level
<MichaelRaskin>
sinit starts a shell script which spawns a Common Lisp daemon that serves requests for privileged operations and also brings up some stuff
<MichaelRaskin>
Like starts the CUPS shell script and PostgreSQL launcher shell script
<qyliss>
IIRC the guix model is to just define services, which sounds nice
<MichaelRaskin>
My opinion is that Nixpkgs is a better structure than NixOS
<MichaelRaskin>
I liked that Sander van der Burg's recent post (find it in NixOS weekly)
<MichaelRaskin>
I didn't find much new for me there, but I endorse the approach
<MichaelRaskin>
(my system is structured closer to Nixpkgs with overrides than to NixOS with modules)
<aanderse>
MichaelRaskin: yeah it was a neat post
<aanderse>
i enjoyed reading
<MichaelRaskin>
A bit obvious and long. But that's probably because I already have thought all of these thoughts before