andi- has quit [Remote host closed the connection]
andi- has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 240 seconds]
drakonis has quit [Ping timeout: 264 seconds]
drakonis_ has joined #nixos-dev
drakonis_ has quit [Ping timeout: 265 seconds]
drakonis_ has joined #nixos-dev
drakonis has joined #nixos-dev
http has joined #nixos-dev
http is now known as nix0n
justanotheruser has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-dev
nix0n is now known as http
orivej has quit [Ping timeout: 240 seconds]
drakonis has quit [Read error: Connection reset by peer]
http has quit [Remote host closed the connection]
sphalerite has quit [Quit: reconfiguring stuff!]
sphalerite has joined #nixos-dev
drakonis_ has quit [Remote host closed the connection]
ixxie has joined #nixos-dev
ixxie has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
ris has joined #nixos-dev
__monty__ has joined #nixos-dev
ixxie has joined #nixos-dev
<arianvp>
fpletz: are you around?
<rycee>
Hey, would like to have some feedback on something that's come up in HM again and again. The presence of "package" options. For example, `programs.urxvt.package` is an option in the urxvt module that specifies which urxvt package to use. The only thing it does is to add the package to `home.packages`, which in turn makes sure the package is in the user profile.
<rycee>
I've been reluctant to add new such "package" options since they don't actually do much and instead have suggested overlays if one want to use a different package version.
<rycee>
But the overlays are a bit tricky for people to use when they simply want to override the package a module uses. Perhaps I was wrong to avoid these options?
<michaelpj>
I think package options make sense in a situation where there are several options that one might want, but where you don't want to disturb the overall use of that package. e.g. if you can use v1 or v2 of a package, but you don't want to override v1 to v2 globally
<timokau[m]>
ü
<rycee>
michaelpj: That's pretty much what I thought as well. So I've added generally added package options when there are multiple versions of the package in Nixpkgs.
<rycee>
Problem is when the user wants to include the same package but, e.g., the Nixpkgs unstable version on a system that otherwise use Nixpkgs stable…
<{^_^}>
#50476 (by Infinisil, 47 weeks ago, open): NixOS services: When to have a package option
<infinisil>
I personally only like these options when there's multiple variants of the package, or if an overlay can't be used (e.g. because it would rebuild lots of other things unnecessarily)
<infinisil>
But from that issue I'm apparently in the minority with that opinion
<infinisil>
Generally I think options should have at least one person that needs them to be justified
<rycee>
I'm starting to tilt towards having more package options :-) Mainly to make it easier for people to override the package. But at the same time I'm not so happy about adding a bunch of options everywhere.
<rycee>
I think part of the trickiness is that there are two ways one might want to override the package. The first being "I want to override the package used in this particular module" and the second being "I want to override the package everywhere" where the first cannot be solved by overlays.
<rycee>
Just passing Dresden, btw. A nice looking cathedral here :-)
<infinisil>
rycee: Maybe the ideal solution would be to have per-module overlays somehow
<rycee>
Hmm, yeah something like that might be a good idea. That would solve both problems and also the hidden problem with the first where you might need multiple packages in the module that should know about each other (which the package option would not solve).
<rycee>
Ooh, a wacky waving inflatable arm flailing tube man on a roof outside the Dresden Hbf!
<ajs124>
rycee: What brings you to Dresden Hbf, if I might ask?
<rycee>
ajs124: I'm on the way from Berlin to Prague by train and we made a stop just now.
<rycee>
The discoverability may not be the best, though. E.g., it's still not obvious (beside from the module name) which package is going to be touched by the module.
<rycee>
But I guess that could be part of the module description.
<ajs124>
rycee: By EC? I always forget how the geography works around these places... That train takes only 30min longer than the new "super fast" ICE takes me from Munich to Berlin.
<rycee>
ajs124: Yeah, EC135 I think it's called. It's pretty quic yeah. We left at 13:00 and should arrive at 17:30 or so.
<rycee>
I actually came to Berlin from Copenhagen via the Munich where the Munich to Berlin was on the ICE. It indeed didn't feel very fast :-)
<ajs124>
Which ICE did you take? There's like 20 ICE connections from Munich to Berlin. Some go over Stuttgart and Frankfurt :D
<rycee>
ICE 1035, the tickets says it takes a little below 2 hours from Munich to Berlin.
<rycee>
So definitely quicker than Berlin to Prague by EC 135 :-D
<ajs124>
ICE 1035 goes from Berlin to Leipzig. I'm 100% sure that the fastest ICE from Munich to Berlin is slightly below 4h. It's a whole thing, called VDE8. 20 years in the making, they ran ads for months when it opened 2 years ago.
rajivr___ has quit [Quit: Connection closed for inactivity]
<worldofpeace>
To test things that rebuild the world I have to add package options locally to give them some sort of testing. so I find them useful for testing things.
<clever>
infinisil: have you seen my crazy builtins.fork idea yet?
<infinisil>
Probably not no
<clever>
infinisil: have you seen how hydra will fork and resume an eval to clear the heap?
<clever>
infinisil: my idea, is to `mapAttrs builtins.fork big-ass-set`
<clever>
and then put each attr, into its own child process
<clever>
and IPC the reads over
<clever>
then the children are disposable
<infinisil>
That sure is an idea
<infinisil>
parallel eval :)
<clever>
it cant be parallel, because the parent is triggering the children and waiting on them
<clever>
but the heap will be spread amung many children
<clever>
infinisil: so far, i have a primop that will fork out a child proc, and setup an ipc to/from it, and return a set containing thunks that write to the child upon being evaled
<clever>
but those thunks just retunr a constant 42
<clever>
the issue, is that i have a set containing { a = <thunk>; }
<clever>
and if i try to eval a.b.c, i need to figure out what type a is, and if its a set, what keys it contains, and sync those over
<clever>
then repeat for a.b, and a.b.c
<clever>
and create magic thunks for every value as i go
<infinisil>
I'm not entirely following, but yes that sounds nice xD
<clever>
infinisil: and its all thanks to importNative that testing is trivial!