<disasm>
yeah, that's me gchristensen! does it work for you? My surfboard wasn't fancy enough to provide any decent stats.
orivej has quit [Ping timeout: 272 seconds]
Drakonis has quit [Remote host closed the connection]
adisbladis has joined #nixos-dev
lopsided98 has quit [Ping timeout: 240 seconds]
lopsided98 has joined #nixos-dev
Ericson2314 has quit [Ping timeout: 276 seconds]
<ekleog>
gchristensen: fwiw, the spamwave appears to be over, #freenode just did their -zm, don't know if you rather keep #nixos-unregistered or not :)
orivej has joined #nixos-dev
goibhniu has joined #nixos-dev
__Sander__ has joined #nixos-dev
<Taneb>
ekleog: still getting spam in another channel :(
<ekleog>
oh. :(
<Taneb>
There was like 17 hours of calm overnight
__Sander__ has quit [Ping timeout: 256 seconds]
__Sander__ has joined #nixos-dev
jtojnar has quit [Remote host closed the connection]
<{^_^}>
nixos-weekly#62 (by domenkozar, 6 days ago, open): Call for Content: 2018/07
<gchristensen>
hmm maybe I can get out my very first nix install matrix report in time, domenkozar
<domenkozar>
excellente :)
phreedom has quit [Quit: No Ping reply in 180 seconds.]
phreedom has joined #nixos-dev
phreedom has quit [Ping timeout: 250 seconds]
stqism has quit [Quit: Like 3 fire emojis lit rn 🔥🔥🔥]
orivej has joined #nixos-dev
<cransom>
oh handy. i too have a 6183.
nwspk has joined #nixos-dev
coconnor has joined #nixos-dev
phreedom has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
Drakonis has joined #nixos-dev
<garbas>
gchristensen: pong
<gchristensen>
garbas: was pandering for reviews on my Travis CI PR :) sorted!
<gchristensen>
they have a _nice_ process for testing language support changes (once it is in a PR, locally is not so nice) and for testing docs changes
<gchristensen>
domenkozar: ^ this is worth posting about to the mailing list, but maybe not until after 2.1 works on Travis :)
<gchristensen>
(pretty boring right now: look! an option which you can't change!)
<domenkozar>
yeah don't think it's much news to say "it wont break"
<domenkozar>
also we shouldn't enforce folks to specify it, but also bump travis-ci once it's tested enough
<domenkozar>
it's going to be hard to support all different nix versions at the same time
<domenkozar>
I'd like to avoid that :D
<gchristensen>
I agree -- keep the default the current release of Nix
<disasm>
ah, I got a 6121 :)
flokli has quit [Quit: WeeChat 2.0.1]
flokli has joined #nixos-dev
pie__ has quit [Ping timeout: 240 seconds]
pie__ has joined #nixos-dev
pie__ has quit [Remote host closed the connection]
nwspk has quit [*.net *.split]
joepie91 has quit [*.net *.split]
samueldr has quit [*.net *.split]
steveeJ has quit [*.net *.split]
samueldr has joined #nixos-dev
pie_ has joined #nixos-dev
steveeJ has joined #nixos-dev
<infinisil>
Is an `openFirewall` option discouraged?
<Dezgeg>
you mean services.foo.openFirewall or something else?
<infinisil>
Yup one of those
<infinisil>
Rewriting the ZNC module to be specific, which currently has an openFirewall option
<clever>
infinisil: i find it handy, i recently used it with plex
<clever>
but it also sorta backfired, plex gives 127.0.0.1 special perms, and because i opened the firewall, i tried to access it remotely, and it refused to even give the option to configure it
<Dezgeg>
sounds quite useful to me, at least it's better than all those random modules which configure themselves to be open in the firewall by default
<clever>
once i used `ssh -L` to forward it, plex thought i was localhost, and easily allowed configuration
<infinisil>
Hmm alright I'll not make an effort to remove it then
<gchristensen>
I think we have a general policy fo not opening ports by default, with openssh being the exclusive exception
<Dezgeg>
yes we do but some have slipped in, IIRC
<clever>
plex's option is set to false by default, so thats all good
<gchristensen>
we should fix them :)
<samueldr>
yes!
cstrahan_ has quit [*.net *.split]
Dezgeg has quit [*.net *.split]
NinjaTrappeur has quit [Ping timeout: 255 seconds]
page has quit [*.net *.split]
guibou has quit [*.net *.split]
pie_ has quit [Ping timeout: 265 seconds]
genesis has quit [Ping timeout: 256 seconds]
Mic92 has quit [Ping timeout: 256 seconds]
pie_ has joined #nixos-dev
genesis has joined #nixos-dev
Mic92 has joined #nixos-dev
<infinisil>
Question regarding naming of NixOS options:
jtojnar has joined #nixos-dev
<infinisil>
I'll be using "*.config" for the config as a nix value, "*.configFile" for the config file generated from it (or manually set by the user)
<infinisil>
But what would you name an option for the contents of the config file as a string? So of type types.lines?
<infinisil>
Or I'd rather actually just get rid of this option
<infinisil>
You can still just do `configFile = pkgs.writeText "foo.conf" "the string.."`
<timokau[m]>
infinisil: or `extraConfig` although thats not exactly the same
<LnL>
it's generally called extraConfig/extraOptions and because it's a lines type it has very different behaviour from overriding the entire config itself
cbarrett_ has joined #nixos-dev
<infinisil>
Yeah
atriq has joined #nixos-dev
<infinisil>
I'll just remove it and add to the error that pkgs.writeText can be used instead
<timokau[m]>
I generally find an option like `configFile` that just overrides all my other config very confusing
<LnL>
you can't tho, you loose all the options generated for you if you need to do that
sphalerite_ has joined #nixos-dev
<LnL>
eg. I can use foo.foo = 42; and foo.extraConfig = '' bar = 42 '';
Taneb has quit [Disconnected by services]
atriq is now known as Taneb
<infinisil>
timokau[m]: I get that, but without such an option you lose the ability to use prexisting configs, and you need to hope that the module is good enough to express your config file (and you have to hope the config is small enough for it not to be painful to convert it)
<infinisil>
LnL: Yeah, but that's intend, I'll also (probably) have extraConfig to append to the generated thing
<timokau[m]>
infinisil: well `extraConfig` provides the best of both worlds
lassulus_ has joined #nixos-dev
sphalerite has quit [*.net *.split]
goibhniu has quit [*.net *.split]
lassulus has quit [*.net *.split]
cbarrett has quit [*.net *.split]
gchristensen has quit [*.net *.split]
cbarrett_ is now known as cbarrett
<infinisil>
Not really, it can't override generated values
<timokau[m]>
You can use the original config syntax or even existing config files (with `readFile`) without having the confusing override behaviour
lassulus_ is now known as lassulus
<timokau[m]>
Well thats the point
<LnL>
yeah that's the other usecase, I might have a full config from somehwere else I want to use
<timokau[m]>
If I wouldn't want the generated values I wouldn't set the corresponding nix options
<infinisil>
Okay well it makes a lot of sense for my case, I won't explain it now though, I want to keep working on it
<LnL>
if they have defaults it'll always be set
<timokau[m]>
LnL: in that case you could still use `extraConfig = builtins.readFile` right?
<timokau[m]>
infinisil: alright :)
<LnL>
no, the nix part usually isn't empty and might influence my config
<timokau[m]>
LnL: so we're commonly setting different defaults than upstream? That seems like a bad idea to me.+
gchristensen has joined #nixos-dev
goibhniu has joined #nixos-dev
<LnL>
well, duplicate values might not be allowed for example
<LnL>
I think both have valid usecases
<LnL>
extraConfig: don't assume the options cover everything, configFile: don't force people to reverse engineer the nix options if they already have a config file
<gchristensen>
seems my message got lost from 20min ago in reponse to infinisil's initial question
<gchristensen>
"sounds like you're doing too much"
<infinisil>
There will only be configFile and config now
Mic92 has quit [Ping timeout: 252 seconds]
<gchristensen>
I think modules that completely / totally represent every config option are doing too much and cause problems with eval time and bugs when the software changes
<srhb>
gchristensen: An example of such breakage? I consider that model to be, well, the model abstraction over foreign software.
<gchristensen>
how is "here is every option" an abstraction? :)
<infinisil>
gchristensen: It's a *single* option representing everything. This option can fully replace the ~20 NixOS options that are used now (and along with it come many advantages)
<gchristensen>
infinisil: oh! cool :)
<samueldr>
there may be two abstractions; making abstraction of the software configuration, where nixos does not have knowledge about software-specific abstractions; abstracting configuration for the user, where the user has a reduced need for software-specific knowledge
<srhb>
gchristensen: Well, okay, interface was the word I should have used :)
<srhb>
Forcing at the very least our primitive type system I see as a benefit, at the very least.
<samueldr>
I'm thinking the "evaluation time issues" shouldn't be an argument whether or not to do this, and it should be looked into *in all cases* (though I don't really have any ideas for that)
<gchristensen>
it is a real cost, though. the strongswan module adds real slow-down to every user, because of how many optionsthere are, even though I doubt more than a few users use it.
<samueldr>
I did ask in the past if there would be issues to somehow gate all options sub-trees behind the modules respective ".enable" options
<gchristensen>
high price
* srhb
nods
<samueldr>
gchristensen: yes, what I mean is I hope to somehow find a way to make those a no-op for the end-users
<samueldr>
I don't know enough about the options system to know whether gating would cause issues, or even be feasible
<infinisil>
It's really hard to do
<samueldr>
I imagine
<infinisil>
Would need major changes to the module system
<infinisil>
(in implementation at least)
<samueldr>
because otherwise I think the modules system becomes kind of a weight, where we have legacy modules with more in-depth options, and no in-depth modules for new things, and this kind of tickles me
<samueldr>
(do note I DO understand how it's hard work and all, just sharing my thoughts)
<infinisil>
Indeed, feel the same way
<infinisil>
Maybe I'll have another go at implementing a better module system
<srhb>
Does guarding the imports in module-list behind the mkIf cfg.enable really do nothing? I think I've asked this before, because it seems cheapish.
<gchristensen>
it makes it (1) hard to know if everything works (2) hard to produce docs for
<gchristensen>
but I think could work
<srhb>
Yes, we need to have some way to let doc and ci "through" the mkIfs
<infinisil>
This doesn't work unfortunately
<gchristensen>
it doesn't?
<infinisil>
imports lists can't depend on config values
<gchristensen>
ah yeah, maybe fixable
<infinisil>
The module system needs to know all modules before it can determine a config value (overrides and merges, etc.), but if the module list is dependent on the config value, then that creates a cycle
<srhb>
Needs more laziness. :-)
<gchristensen>
Eelco proposed deferring module loading to the user
<gchristensen>
imports = [ <nixos/module/nginx> ] etc.
<samueldr>
I would 👍 that
<samueldr>
a bit less user-friendly, but makes it extremely obvious where modules come from
<infinisil>
Not a fan of that, it takes away one of the biggest magic tricks of NixOS
<srhb>
I think that's a pretty big cost for new users
<samueldr>
yeah
<gchristensen>
that is why I didn't like it
<LnL>
not a fan either, unless we do something like splitting up modules into 2 categories
<samueldr>
though, groups of modules could exist?
<clever>
samueldr: nothing is stopping several different modules from mkIf'ing against the same .enable
<infinisil>
LnL: Yeah just thought of that too
<clever>
which sort of gets you the same flexibility of if's in imports
<samueldr>
oh right
<infinisil>
clever: Except it doesn't solve the evaluation time problem
<srhb>
How bad is the evaluation time problem?
<infinisil>
I think it increase 3fold over the last 2 years or so
<clever>
infinisil: yeah, thats still an issue
<infinisil>
increased*
<clever>
srhb: ive seen a nixops deploy that uses over 32gig of ram, due to multiple instances of nixos in it
<gchristensen>
it is probably reasonable to start splitting up NixOS in to a standard distribution, and then an ecosystem of package sets and modules
<LnL>
I do wonder if submodules could be made lazy
<srhb>
clever: Not just the usual leakage?
<clever>
srhb: hard to tell the difference witht he current tooling
<LnL>
where only defining submodule values would trigger the type to get evaluated
<srhb>
It just saddens me. More tailored options means more restriction on which bad configs you can accidentally let through
<srhb>
If we just stringify everything, a lot of safety goes out the window.
<infinisil>
LnL: I once thought that should be the case already, but then I tested it and it's not. I think the reason is the man pages
<LnL>
no, the types are strict
<LnL>
oh :/
<LnL>
didn't even think about that
<infinisil>
srhb: That's the reason I'm doing this "nix value as config" thing. It's a good middleground. No invalid config semantically, but options could still be invalid
<srhb>
infinisil: Good point.
<LnL>
we could turn that into an actual package tho
<infinisil>
LnL: Needs to be evaluated with each NixOS build though
<LnL>
not if it's a package in nixpkgs that just takes the source as inout
<infinisil>
What if you add an option and rebuild?
<infinisil>
Currently it shows up in man configuration.nix
<LnL>
like your own option?
<LnL>
yeah, I think it's fine if it doesn't
<infinisil>
Not even, you add one to nixpkgs (with a nixpksg fork)+
<infinisil>
Hmm.. I'm currently often using the man pages to check whether i formatted my descriptions correctly
<LnL>
then either it doesn't use it or you override the manpages to use your fork which would trigger a rebuild of the package
<samueldr>
let's say I'm distributing a "options set" and making users import it, I'd like it to show up under man configuration.nix
<LnL>
then build the manpages
<infinisil>
Heh, how about having a man page for every option :P. So e.g. `man nixos.services.openssh`
<LnL>
either way you only pay the evaluation price once per nixpkgs revision
<gchristensen>
"The other argument is (lack of) maintainability: we're basically replicating the entire thermald configuration language in NixOS, so every time thermald adds an option, we'd have to update the NixOS module to make it available to users. We also have to duplicate all option descriptions from the upstream documentation, which is also not very nice - it's better to just refer to the upstream docs." is what
<gchristensen>
Iwas thinking about.
<srhb>
I think that undervalues the "you don't have to learn every silly thing out there" parts of NixOS :P
<gchristensen>
I disagree
<gchristensen>
if you make an option for everything, you have to learn every silly thing.
<gchristensen>
if there are opinionated options that do the common right thing, that is very powerful
<LnL>
gchristensen: that's a very good point
<LnL>
the main argument for these is validation
<srhb>
I can't count the amount of times I've been saved by even simple stanzas being guarded behind a completely trivial type check.
<srhb>
Or simply saving me from knowing the syntax.
<gchristensen>
srhb: you're not, but still: we don't need to expose every option
<LnL>
well but that can be solved in a much better way, that's both more correct and doesn't have an evaluation cost
<infinisil>
gchristensen: The good way about my nix-value-as-config is that you can have both: special options can set this nix value to the thing they encode, while users can also use the config directly
* samueldr
thinks there are two discourses here
<LnL>
eg. using nginx's check functionality to guard against an invalid config
<LnL>
and this can be done during nixos-rebuild build similar to evaluation failures
<samueldr>
I think there may be two orthogonal discourses that maybe shouldn't be mixed as their resolutions shouldn't be dependent on eachother