andi- has quit [Remote host closed the connection]
andi- has joined #nixos-dev
mjsir911 has joined #nixos-dev
<mjsir911>
Hello. So I'm trying my hand at improving a nix package and I would like to be able to write it's configuration file through an untyped dict as the config file looks a lot like that (like `services.znc.config`)
<mjsir911>
Problem is the configuration file is typed and it differentiates between `bytes` and `string` & `uint` and `uint64`. Is there any right way to provide that information through a nix config file?
cjpbirkbeck has joined #nixos-dev
cjpbirkbeck has quit [Quit: Quitting now.]
drakonis has quit [Quit: WeeChat 2.6]
harrow` has joined #nixos-dev
ddima_ has joined #nixos-dev
harrow has quit [Quit: Leaving]
ddima has quit [Ping timeout: 245 seconds]
harrow` has quit [Ping timeout: 276 seconds]
harrow has joined #nixos-dev
<srhb>
Alright, bisect done. Looks like bonds were broken in either 8c7e588362e708ade5e782c09dbdf84d06ab4254 or 1f03f6fc43a6f71b8204adf6cd02fb3685261add with the first being more likely, since that's the systemd -> 242 upgrade.
<srhb>
I'll write down some notes on what's going on later, but the short story is that bonds apparently make up (random?) MAC addresses and then set the bonded devices hwaddr to the same, when the default behaviour _should_ be to set the bond MAC to that of the first device and _then_ set the same hwaddr for the remaining devices.
<srhb>
I guess I'll bisect systemd too, if it's not too hard...
sphalerite has joined #nixos-dev
Jackneill has joined #nixos-dev
xwvvvvwx- has quit [Read error: Connection reset by peer]
obadz has joined #nixos-dev
orivej has joined #nixos-dev
eraserhd has quit [Ping timeout: 252 seconds]
justanotheruser has quit [Ping timeout: 240 seconds]
xwvvvvwx has joined #nixos-dev
xwvvvvwx has quit [Read error: Connection reset by peer]
xwvvvvwx has joined #nixos-dev
xwvvvvwx has quit [Read error: Connection reset by peer]
__monty__ has joined #nixos-dev
psyanticy has joined #nixos-dev
xwvvvvwx has joined #nixos-dev
xwvvvvwx has quit [Read error: Connection reset by peer]
xwvvvvwx has joined #nixos-dev
greizgh has quit [Quit: greizgh]
xwvvvvwx has quit [Ping timeout: 276 seconds]
<Profpatsch>
mjsir911: Is that a nixos module or a normal package?
matthewbauer has left #nixos-dev ["Kicked by @appservice-irc:matrix.org : 30 day idle timeout."]
Synthetica has joined #nixos-dev
<arianvp>
srhb: thanks for digging. Please update the tracking issue with findings. Scrolling through irc is a bit hard
orivej has quit [Ping timeout: 240 seconds]
<arianvp>
:D
xwvvvvwx has joined #nixos-dev
<mjsir911>
uhhh im not sure about the terminology. I want to modify the module softether so I can set `services.softhether.config` to an arbitrary dict in my configuration.nix file that gets translated to a config file when I build it
xwvvvvwx has quit [Ping timeout: 250 seconds]
xwvvvvwx has joined #nixos-dev
xwvvvvwx has quit [Read error: Connection reset by peer]
xwvvvvwx has joined #nixos-dev
<infinisil>
mjsir911: Can you show an example of a config file?
<mjsir911>
yeah, 1 min
<infinisil>
mjsir911: And btw, in rfcs#42, it was decided to call such options `settings` instead of `config` so it's less confusing
<mjsir911>
problem being differentiating between "byte" type and "string" type, which the application absolutely wants to be the correct one
xwvvvvwx has joined #nixos-dev
<infinisil>
Hm, the idea is really to not use this technique for config files that don't have a clear one-to-one mapping from nix values, and that seems to be the case here
<infinisil>
It could still be doable, but it won't be as straight-forward
<mjsir911>
Alright, that's too bad. I'de still like to try to do it, but I might just have to stick with the byte type
<infinisil>
mjsir911: You could encode values like `mkValue "byte" "11111=="`
<infinisil>
mkValue = type: value: { inherit type value; }
<infinisil>
And then have some special logic to detect these, while guessing the type for everything else
<mjsir911>
thats a good idea. Would I still be able to use normal strings without mkValue and translate them to `string` type?
<gchristensen>
"Updates and installations in a clone with atomic new system switch on reboot"
<gchristensen>
looks like the Makefile patch didn't fix it
<gchristensen>
oh lol
FRidh has quit [Quit: Konversation terminated!]
xwvvvvwx has quit [Read error: Connection reset by peer]
xwvvvvwx has joined #nixos-dev
xwvvvvwx has joined #nixos-dev
eraserhd has joined #nixos-dev
xwvvvvwx has quit [Ping timeout: 265 seconds]
xwvvvvwx has joined #nixos-dev
xwvvvvwx has quit [Read error: Connection reset by peer]
xwvvvvwx has joined #nixos-dev
justanotheruser has joined #nixos-dev
<gchristensen>
y'all this is a great document
ixxie has joined #nixos-dev
<gchristensen>
> ubuntu_<uuid> datasets have a org.zsys:last_used properties, refreshed when mounted at boot and shutdown times. Those are used to track regular usage of those datasets.
<{^_^}>
error: syntax error, unexpected ',', expecting ')', at (string):269:60
drakonis has joined #nixos-dev
mog has left #nixos-dev [#nixos-dev]
orivej has joined #nixos-dev
http has joined #nixos-dev
http is now known as nicks0n
drakonis has quit [Quit: WeeChat 2.6]
drakonis has joined #nixos-dev
nicks0n has quit []
<mjsir911>
Are recursive functions a thing in nix?
drakonis1 has quit [Ping timeout: 240 seconds]
drakonis has quit [Ping timeout: 246 seconds]
drakonis has joined #nixos-dev
<niksnut>
the greatest thing about 19.09 is having emojis in konsole
<worldofpeace>
yay
<worldofpeace>
Jan Tojnar: and I did this ❤️
<teto>
worldofpeace: <3
<worldofpeace>
jtojnar++
<{^_^}>
jtojnar's karma got increased to 13
<gchristensen>
:D
<Profpatsch>
mjsir911: yeah
<Profpatsch>
mjsir911: let fix = f: let x = f x; in x; in fix (old: { a = old.b + 2; b = 2; })
cjpbirkbeck has joined #nixos-dev
<Profpatsch>
> let fix = f: let x = f x; in x; in fix (old: { a = old.b + 2; b = 2; })
<{^_^}>
{ a = <CODE>; b = 2; }
<Profpatsch>
> let fix = f: let x = f x; in x; in builtins.deepSeq (fix (old: { a = old.b + 2; b = 2; }))
<{^_^}>
<PRIMOP-APP>
<Profpatsch>
> let fix = f: let x = f x; in x; in let res = (fix (old: { a = old.b + 2; b = 2; })); in builtins.deepSeq res res
<{^_^}>
{ a = 4; b = 2; }
<Profpatsch>
Hah!
<infinisil>
> :p let fix = f: let x = f x; in x; in fix (old: { a = old.b + 2; b = 2; })
<{^_^}>
{ a = 4; b = 2; }
avn has quit [Ping timeout: 268 seconds]
greizgh has joined #nixos-dev
freepotion has joined #nixos-dev
ris has joined #nixos-dev
<freepotion>
Hey all! Is the presence of my email in the list of maintainers strictly necessary? Can I remove this field or specify an empty value? Especially if my github id is listed?
<Profpatsch>
infinisil: Oh, it’s just a nix repl :P
<infinisil>
It isn't!
Jackneill has quit [Remote host closed the connection]
<Profpatsch>
freepotion: Hm, good question cc gchristensen
<Profpatsch>
freepotion: Spam-related?
<Profpatsch>
I don’t think I get any more spam because of this.
<gchristensen>
freepotion: strongly preferred
<samueldr>
there's a couple users in there using `@users.noreply.github.com`
<freepotion>
Profpatsch: No, but it happens that I want to change my email, and I don't want to open the PR every time after that :)
<infinisil>
New matrix-synapse version, which added and removed a bunch of options, all of which need a change to the module
<infinisil>
And the module is now 730 instead of 702 lines long
<infinisil>
500 lines of which are just option declarations..
<qyliss>
I'm extremely pro your RFC, but I don't think line length of options really matters
<qyliss>
it's easy enough to skip them
<qyliss>
if you don't care about them but need to do something else in the file
<infinisil>
qyliss: Problem is all the maintenance required for these, which ends up not getting done ever
<infinisil>
E.g. a description needs to be changed, type change, default change
<qyliss>
Yeah that sucks
<infinisil>
Another problem is that it leads people to add more of these options in the future, which again is more maintenance
<qyliss>
although the alternative is no types, no defaults, and no descriptions
<infinisil>
That's upstream's responsibility to document all fields
<infinisil>
We can still copy them for a couple important ones though
<infinisil>
(as indicated in the rfc)
<qyliss>
yeah
<qyliss>
I'll be proposing a module with about 300 lines of option declarations soon fwiw
<qyliss>
I'd argue pretty much all of them are important and necessary
<infinisil>
Hmm
<arcnmx>
fwiw I feel a bit torn on it overall depending on how the check/assertion parts play out and how it mixes with "blessed" settings, but I haven't read through the thread to see what kind of thoughts/conclusions came about from it
<infinisil>
arcnmx: I don't think there would be any problems with that, can you expand a bit?
<qyliss>
It's currently 200 lines of option declarations, but I wanted to leave myself some room because it might need a few more
<infinisil>
qyliss: Ah yeah, such higher-level options I'm totally fine with, I think those are great and should be encouraged
<infinisil>
(higher level than just the config file)
<qyliss>
well, a few of those are just the config file
<qyliss>
but I think it would be a shame if a novice user had to know the difference
<qyliss>
for advanced use cases, I'm totally fine with .config
<arcnmx>
infinisil: just the part regarding the loss of documentation of settings in nixos and eval-time type checks does seem bothersome? And perhaps not being able to intuitively know whether a given setting should go in service.thing or service.setting.thing? I need to look over it more though probably!
<qyliss>
But my principle has been it should at least be possible to get a basic setup with everything working without needing to use it
eraserhd has quit [Quit: WeeChat 2.6]
<infinisil>
qyliss: Ah yeah that's fine, very inline with the rfc :)
eraserhd has joined #nixos-dev
<qyliss>
:)
<qyliss>
arcnmx: I reckon an option being confusing enough that it would benefit from type checking would be a good rationale to add it as a proper option
<infinisil>
arcnmx: Hm yeah that's a necessary evil, but I think upstream up-to-date docs are better than flooding the nixos option listing with outdated ones that may make modules break for new versions
<qyliss>
But I speak only for myself there
<arcnmx>
what I always felt I wanted was just a submodule with a special everythingElse attr that collected anything not explicitly an option? but maybe that's too magical o:
<qyliss>
arcnmx: what's the difference between that and the .config proposed in the RFC?
<infinisil>
arcnmx: Yeah that's not unheard of, some people have wanted that already. I'm not sure if it's a good idea to implement this though
<arcnmx>
and maybe not as useful in practice as it sounds, mostly I've wanted it to paper over unfinished modules I think
<qyliss>
Yeah some modules just need some expansion
<infinisil>
qyliss: I think arcnmx means that we should have a type like a submodule but where you can set any option, even if it doesn't exist, and all the non-existent ones get collected into an unstructured attrset
* qyliss
looks pointedly at nginx.nix, which doesn't support streams
<qyliss>
infinisil: oh, right
<qyliss>
I think I don't like that because you would be surprised if you typoed an option name
<qyliss>
but no strong feelings
<infinisil>
I think it might be a bad idea because it can be confusing what happens when you set a thing. If you make a typo for example it will be unstructured without type checking
<infinisil>
And you won't get an error
<qyliss>
yeah exactly
<infinisil>
Maybe it's not too bad though
<arcnmx>
Yeah it has its tradeoffs, though typo'ing .settings.soemthing sounds similar to the same problem
<infinisil>
Yeah, at least there's a clear separation though
<arcnmx>
Mmhm, so specifically when you want to use an explicit setting it can't happen. Dunno, probably don't have strong feelings either way, just overall torn on less discoverability/intuitiveness combined with... more need to consult documentation which will have less useful info and need to link to external option lists?
<qyliss>
I think the idea here is that it'll largely affect things where you can't trust the documentation to be maintained properly anyway?
<arcnmx>
As a user I'd miss being able to just skim nixos options page, as a module writey person I'll perhaps like the reduced burden but also probably feel obligated to add as much in the form of assertions or whitelists or whatever.
<qyliss>
again, if you're asserting on an option, it should probably be a real option
<qyliss>
IMO
<infinisil>
arcnmx: think of it as having smaller but higher quality modules
<qyliss>
infinisil: any option referenced in Nix code should definitely be an option, right?
<qyliss>
I don't like the idea of us reaching into .config
<arcnmx>
Well, taking synapse for example... awful documentation, awful software to configure, yet nixos made it easy to do so by just skimming the module/docs. The intent to do away with most of those explicit options would've made that a much more painful experience, I believe.
<infinisil>
I'm personally disappointed of the general quality of modules in nixpkgs
<arcnmx>
but that makes it mostly about discoverability if anything else, and I do agree overall
<infinisil>
qyliss: Doesn't have to be, i think it would be best to decide options purely on whether they're useful for most users
justanotheruser has quit [Ping timeout: 240 seconds]
<qyliss>
hm
<qyliss>
I might take this to the RFC then
<qyliss>
because I do feel strongly about that
<infinisil>
qyliss: Hm I guess it's a bit of a problem if the wrong type is provided
<infinisil>
Because it would be annoying to check for that whenever you use a value from .settings
<qyliss>
Yeah exactly
<qyliss>
config should be completely unstructured
<qyliss>
using values out of it is imposing structure on it
<qyliss>
but then that structure is implicit
<qyliss>
and maintenance becomes even harder
<arcnmx>
I guess my issue potentially lies in that it may be arbitrary where the line lies for a setting important enough to place in .settings vs top-level, and whether simply wanting to validate a setting means placing it in one or the other in order for nixos-options to be able to document it?
<qyliss>
because you might not notice that when you're doing an update
<Profpatsch>
infinisil: Thought: usability would be if you could trivially open the docs for a config element.
<infinisil>
qyliss: I don't like how this would make even tiny useless options have to be exposed like that
<Profpatsch>
e.g. upstream manpage or html
<arcnmx>
and yeah, if it's used by other expressions like that, but wasn't previously a setting, it seems to encourage backward-incompatible changes to move it out.
<Profpatsch>
Then you don’t need to copy options per se.
<infinisil>
qyliss: We almost need a type-checking stage that doesn't need options declared
<qyliss>
infinisil: what would be the point of that?
<qyliss>
fewer lines??
<qyliss>
no description?
<infinisil>
Profpatsch: That would be neat yeah
<infinisil>
qyliss: That only the important options are listed in the options listing
<infinisil>
Not a sea of unimportant options, but the couple ones most people will want to use
Synthetica has quit [Quit: Connection closed for inactivity]
<qyliss>
hmmmmmmm
<qyliss>
Isn't that what the manual is for?
<infinisil>
Type checking on some .settings values would then be strictly so the module doesn't break because it expects something different
<qyliss>
I think I disagree with how far this is being taken
<infinisil>
qyliss: You mean the manual with sections and stuff?
<qyliss>
yeah
<qyliss>
If we're imposing structure on a value, that should be documented
<infinisil>
I'm personally mostly looking at options when trying to use a module, and many others probably too
<qyliss>
An options.html that fails to actually tell you what structure NixOS imposes would be useless IMO
<infinisil>
Checking to see if the manual has a section on this module is an afterthought
<qyliss>
because you'd have to go and read the source anyway
<qyliss>
or deal with failure after failure
<arcnmx>
Though, that's probably a problem of discoverability and the option description could link to the relevant section?
<infinisil>
arcnmx: Probably yeah
<qyliss>
Yeah it should be idiomatic to do that in mkEnableOption
<arcnmx>
as well as the upstream docs for the unstructured options themselves
<qyliss>
I'd be very not happy with an options.html that's deliberately hiding things from me (even more so than it currently does)
<infinisil>
qyliss: Regarding the "If we're imposing structure on a value, that should be documented", upstream can impose much more structure than we can check for, which will be noticed at runtime
<qyliss>
right
<qyliss>
that's upstream's responsibility
<qyliss>
but we're responsible for the assumptions that we make
<qyliss>
because what upstream does could change
<infinisil>
Hm
<infinisil>
qyliss: Okay I guess the .settings we use in the module directly usually aren't that many, would probably be no problem to have separate options for them
<infinisil>
I can only think of .settings.port right now
<infinisil>
Which is also important enough to warrant its own option anyways
* qyliss
nods
<qyliss>
We should talk about this on the RFC
<qyliss>
tomorrow maybe when I'm not tired
<infinisil>
Issues is a terrible place to discuss though!
<infinisil>
s/is/are
<infinisil>
And every new comment in the RFC actually discourages people from discussing more because it gets bigger and bigger haha
<qyliss>
Well yeah I agree
<qyliss>
what I mean is, the RFC should be clear about this
<qyliss>
GitHub is a terrible discussion interface
<qyliss>
but people don't like mailing lists, so...
* infinisil
isn't a fan of mailing lists either
<arcnmx>
:(
<infinisil>
Isn't there some platform that focuses on discussions?
__monty__ has quit [Quit: leaving]
<infinisil>
E.g. where different points can be discussed in parallel threads, counterarguments, showing where the conflicts are, etc.
<infinisil>
That would be neat
drakonis1 has joined #nixos-dev
<qyliss>
infinisil: loomio
<qyliss>
but in practice it's not so nice to use
justanotheruser has joined #nixos-dev
<infinisil>
:o
<qyliss>
mailing lists, i will point out, have parallel threads, and a thread overview will show you where conflicts ;)
<infinisil>
Ehhh, I think that's a bit of a stretch
<arcnmx>
heh, my only problem with mailing lists is I don't have a good mail client :(
<infinisil>
qyliss: Okay I guess it's better than just linear IRC
<Profpatsch>
Mail threads are in theory a DAG, just there is no nice interface for that.
<infinisil>
Profpatsch: A tree too probably?
<Profpatsch>
sure, that’s included
<infinisil>
Well not all dags can be represented as trees
<infinisil>
But I don't think email threads can be "merged"?
<Profpatsch>
yeah, but the other way around
<Profpatsch>
yep, they can
<Profpatsch>
But no client will show you that.
<infinisil>
Oh just quote multiple mails?
<Profpatsch>
Set In-Reply-To to multiple IDs
<Profpatsch>
I mean, just map that whole shebang onto git refs, done.