<Profpatsch>
genesis: you mean how long it takes for something to go to nixos 19.09 for example?
<Profpatsch>
Usually until the next release, except for security patches
<Profpatsch>
You can request a backport of a new package though.
<Profpatsch>
And then what to brush, idk, just follow a good and dentist-approved routine
<genesis>
oki thanks
<LnL>
hmm, cross compiled nix depends on gcc :/
<aanderse>
so should we remove the "new services" section of the release notes? or, alternatively, actually fill it out from now on?
<aanderse>
i'm pretty guilty of never adding to it i realized...
<infinisil>
aanderse: I feel like filling it out once for all modules when the release is happening is less painful than filling it out every time a module is added
<infinisil>
No need for many people to mess with xml and no need to point it out to people
<infinisil>
And also I feel like this kind of thing should be automated anyways
<aanderse>
infinisil: discourse thread created
<infinisil>
E.g. by having a `meta.introducedIn = "19.09"` field in modules
<gchristensen>
on the other hand, I sort of think it would be good to have the PRs adding services document it in the "new services" section with a user-focused perspective about why people should care
<aanderse>
seems like a good idea, though who will do that i wonder...
<aanderse>
gchristensen: also a very good point
<aanderse>
:)
<aanderse>
you cared enough to create a module... show it off to the world! ;-)
<infinisil>
gchristensen: Wouldn't this be better in a general doc section instead of the release notes?
<gchristensen>
perhaps
<gchristensen>
in my mind it would create a bit of a filter on what modules get added
<__monty__>
Though the release notes are an ideal place to find out about new things.
<infinisil>
__monty__: How about having docs for all modules in a general place, but link to those from the release notes
<__monty__>
That could be fine. Doesn't reduce work for anyone though. I'd expect the release notes to be one-liner motivations for the new services. I'd still expect that one-liner to be *in* the release notes even if they also link to a place with more info.
v0|d has quit [Ping timeout: 248 seconds]
<infinisil>
__monty__: I like the idea of using module meta fields for this. `meta.introducedIn` and `meta.docString` or something like that
<infinisil>
To make it super easy, without having to mess with xml files
<infinisil>
(Ideally docString would be markdown or so!)
<infinisil>
If a docString is present, convert that to a section on the module in the general manual section, and link to it from the release notes for the release from introducedIn
<infinisil>
gchristensen: On a related note: I'm probably gonna investigate improving the module system speed today, like by a lot, hopefully, then we shouldn't worry as much about which modules to include
<aanderse>
infinisil++
<{^_^}>
infinisil's karma got increased to 170
<infinisil>
that is, again, I've done that like twice before
<aanderse>
20+ machine nixops networks aren't super fast
<aanderse>
infinisil: if you can remember to do you mind pinging me on any PRs you make to increase speed? just informational :)
<qyliss>
Isn't this the sort of thing we could have an OfBorg check for or something?
<qyliss>
I agree with gchristensen that it would be better written by the module authors
orivej has joined #nixos-dev
<infinisil>
aanderse: I'll try to :)
<__monty__>
As a maintainer I agree that it seems unnecessarily burdensome to have to reverse engineer a reason for adding a service for X-ty services. But a meta.docString rather than having to manually write xml seems great.
<gchristensen>
qyliss: definitely :)
<gchristensen>
infinisil: I still want to worry some, speed isn't everything -- having a curated set is useful for users
<qyliss>
gchristensen++
orivej has quit [Ping timeout: 265 seconds]
<MichaelRaskin>
Re: having a curated set is useful for users — having more stuff also is, and curated set with a ton of curators and no clear criteria doesn't sound that great
<aanderse>
thanks
drakonis has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.6]
<infinisil>
gchristensen: Yeah
<infinisil>
I also have this idea of separating NixOS modules into unstable/stable. When people add a module, it is an unstable one by default. Only after the module has been extensively put to the test and refined it can become stable
<infinisil>
This allows us to do changes to unstable modules even after introduction without worrying about backwards comp (because those don't have any such guarantees)
<infinisil>
I should've seen this earlier, but whether you set options is one thing, but whether those options are *accessed* is another
<infinisil>
While I was able to not load modules when options aren't set, they should be loaded anyways when they are accessed, but there is no way to detect whether options are accessed, I think
<infinisil>
Oh although, maybe I can work around that..
<infinisil>
Nah, it just doesn't work.. :(
<infinisil>
It might work with a builtins.tryEval, but that's kind of ugly..
<infinisil>
Eh, I guess anything is better than our awful eval times, I'll look into using builtins.tryEval
<infinisil>
Never mind, that won't work
<infinisil>
> builtins.tryEval {}.foo
<infinisil>
error: attribute 'foo' missing, at (string):1:18
<infinisil>
tryEval can't recover from that
<MichaelRaskin>
Wait for testing attribute presence you do not even need tryEval
<MichaelRaskin>
Just ?
<infinisil>
MichaelRaskin: If bob uses config.networking.whatever in some NixOS module for example, without ever setting that value
<infinisil>
The module that defines whatever needs to be included, but there's no way to know that bob accesses whatever
<MichaelRaskin>
(time until infinisil proposes a property-like mechanism for Nix: 3… 2… 1…)
<infinisil>
Not sure what you mean by that!
<MichaelRaskin>
Getters or metatables or overloadable lookup function or whatever
<MichaelRaskin>
The only real solution is, of course, looking at Nixpkgs and finding a way to build a system out of «just» overlays
<infinisil>
Hm I'm not sure about that, overlays are very imperative
<MichaelRaskin>
Well, the main code is all on the pure functional level
<MichaelRaskin>
Then overlay-style override can be used for configuration
<MichaelRaskin>
After all, module system is emulating writeable shared state with duistributed access…
<infinisil>
It's not real state though, since all options are only written once
<infinisil>
Nothing can be changed
* gchristensen
thinks about definable merge behavior
<MichaelRaskin>
I would say that with all the mkForce and defineable merge, «nothing can be changed» sounds more like a fatalistic statement, than as a promise
ryantm has quit [Quit: leaving]
ryantm has joined #nixos-dev
<infinisil>
Hm, thinking about how this situation can be rescued in the best way
<infinisil>
And one idea is to require modules to declare `usesConfig = { networking.whatever = true; }` as the set of config values they need to access
<infinisil>
It's not very nice but it's the best thing I can imagine being possible without huge amounts of work
<infinisil>
(where huge amounts of work = a module system rewrite fully incompatible with the current one)
<MichaelRaskin>
Yay, full NixOS configuration system redesign.
<infinisil>
MichaelRaskin: Hm, why do you think something like overlays are the way to go for system configuration?
<MichaelRaskin>
Well, it is a cleaner approach in terms of evaluation flow, and seems to scale well enough for Nixpkgs?
<infinisil>
MichaelRaskin: What would be the benefit for end users?
<infinisil>
I feel like it would have an overall worse experience
<infinisil>
It's hard to beat services.foo.enable = true;
<MichaelRaskin>
services = [ … foo ];
<MichaelRaskin>
Doesn't actually seem worse
<infinisil>
MichaelRaskin: And in another module it would be `services = old.services ++ [ bar ];`?
<infinisil>
If you miss the old.services they get cleared
<MichaelRaskin>
Well, the user lists top-level services, the dependencies get included inthe background
<MichaelRaskin>
Like with packages
<infinisil>
But if you want to have some modularity
<infinisil>
Set services in multiple files
<infinisil>
as a user
<MichaelRaskin>
And packages As a user I want an evaluation logic that is not a damned magic show and does not take forever
<MichaelRaskin>
I think by now evaluating a test NixOS VM with empty configuration takes longer than evaluating my actual system
<infinisil>
That is an argument :)
<MichaelRaskin>
(my actual system is not NixOS, uses hand-written bootscripts and a few layers of overlays)
<MichaelRaskin>
In the old old old times, when NixOS config was plain data, I wanted some modularity just for my _package list_ of all things.
<MichaelRaskin>
Sure, I quickly wrote a few files that took the parameters like pkgs: and returned values — lists of packages — separated by topic
<MichaelRaskin>
Then on the top level, whatever = whatever_web ++ whatever_partitions; or something
<infinisil>
Hm
<infinisil>
I think one very benificial thing on the module system is that it allows you to write a module that does a couple things which you can just load and it works, without having to go to lengths to figure out how to apply its changes
<MichaelRaskin>
Yep, that's how every system with spaghetti global variables is motivated in the beginning
<MichaelRaskin>
In principle, overlay-based configuration obviously allows you to write some module that you just say .override{import ./module.nix;} and it magically does everything…
<MichaelRaskin>
But with module system this is more or less the only way of doing things
<infinisil>
Hmm I guess that's still possible with overlays yeah
<infinisil>
MichaelRaskin: Do you have your code online?
<infinisil>
I believe this was asked before but I think the answer was no
<MichaelRaskin>
Monotone is an actual DVCS and not that Git undesigned horror optimised for FS no longer in use
<MichaelRaskin>
But now it is effectively dead
<MichaelRaskin>
Which doesn't mean it stops working, of course…
<infinisil>
MichaelRaskin: Where's like the top-level file?
<MichaelRaskin>
local/test-system-thinkpad.nix
<infinisil>
MichaelRaskin: This doesn't have any type checking as of now right?
<infinisil>
I guess that could be added though
<MichaelRaskin>
It doesn't, its goal is just to support the real stuff happenning in the Lisp code
<MichaelRaskin>
Just happens to be large enough to demonstrate the structure I prefer
<infinisil>
And I guess also some utils for things like `nixOptions = super.nixOptions // { extraOptions = super.nixOptions.extraOptions or "" + ` could be implemented
<MichaelRaskin>
And I guess RFC#42 would provide some nice cleanups
<MichaelRaskin>
Because it is really completely generic and doesn't depend on anything above or below it
<MichaelRaskin>
Just «maybe we should have a generic-ish abstraction of configuration file»
<infinisil>
Hmm
<MichaelRaskin>
And of course Nixpkgs package files (default.nix) are insanely more reusable than NixOS modules…
ivan has joined #nixos-dev
<infinisil>
I give up on this for today, module speed improvement failed for the most part