<Profpatsch>
siraben: lib is a pure library of nix functions that only depends on builtins
<Profpatsch>
It’s exposed via pkgs.lib
<Profpatsch>
I don’t know why pkgs.stdenv.lib even exists, possibly an artifact from the very early days of nixpkgs
<Profpatsch>
lib could even be hosted separately from nixpkgs and it would still work
<V>
I pretty much only write out stdenv.lib explicitly when it's the only place I'm using lib in that file (e.g. meta with-clause), and it makes no logical sense to do so as it's not part of stdenv and does not vary between stdenv
<siraben>
So we should seek to stop using `stdenv.lib` in packages?
<V>
I do not know why stdenv contains it
<Profpatsch>
yes
<Profpatsch>
you can already do { lib }: in your package header
<Profpatsch>
And it just works
<siraben>
Right
<siraben>
supersandro2000: hm, maybe you want to adjust your reviews accordingly
<siraben>
IIRC you recommend stdenv.lib over lib
<Profpatsch>
I consider it a minor problem, but certainly we shouldn’t tell people to use stdenv.lib
<siraben>
If I did a PR to remove all occurences of stdenv.lib, would that be good?
<siraben>
in Nixpkgs
<qyliss>
siraben: I'd wait a bit in case anybody has serious
<Profpatsch>
There’s also pkgs-lib, which infinisil recently introduced because it it a library but it depends on a few things in nixpkgs.
<qyliss>
in case serious objections come up with formalising it in documentation
<Profpatsch>
So we opted for splitting it off rather than making lib depend on nixpkgs
<siraben>
qyliss: I see
<siraben>
Profpatsch: where's pkgs-lib?
<qyliss>
but at some point in the future, maybe a couple of months down the line, I think that would be nice
<Profpatsch>
qyliss: If we remove any trace of it in nixpkgs it amounts to the same thing no?
<qyliss>
siraben: pkgs/pkgs-lib
<qyliss>
Profpatsch: I don't understand
<Profpatsch>
qyliss: I mean we don’t need to doc the preference if we don’t have any remaining examples
<qyliss>
well that's true
<Profpatsch>
Because nobody would ever think to use stdenv.lib in that case
<qyliss>
but I think that has to be step 2
<Profpatsch>
we can even add a trace warning
<Profpatsch>
yeah
<Profpatsch>
But tbh, why bother
<Profpatsch>
It’s not like it’s a semantic problem
<siraben>
It's confusing I think to think lib is under stdenv
<qyliss>
Profpatsch: one less thing for newcomers to get confused about?
<Profpatsch>
true
<siraben>
And we can do treewide PRs
<Profpatsch>
Oh man, I *love* monorepos :)
<V>
lib is just <nixpkgs/lib>. stdenv has nooothing to do with it
<Profpatsch>
I hope that doesn’t go away SMILEY
<qyliss>
I think we'd have to keep it around, for external code
<V>
:)))))))
<qyliss>
could add a trace that it's deprecated
<qyliss>
but we're getting ahead of ourselves
<qyliss>
let's let the doc change settle down first
<siraben>
So maybe it should be a more formal discussion heh
<siraben>
yeah
* siraben
puts sed away
<V>
we're definitely getting ahead of ourselves, I've been trying to find where it's set for the last 10 minutes
<Profpatsch>
Hm, I don’t see much reason for discussing the doc change
<Profpatsch>
It’s a trivial simplification after all.
<Profpatsch>
And the sed can come if somebody finds the time
<qyliss>
and definitely not for a couple of months
<Profpatsch>
I mean the projects lives from people doing small simplifications like these, since it removes accidental complexity and makes new stuff possible
<siraben>
Right, one less thing to worry about.
<siraben>
Hm it's not entirely non-trivial to make this treewide change since it may involve some AST-sensitive changes
<siraben>
I've had to do manual treewide PRs a few times because of lack of meta-programming
<siraben>
not entirely trivial*
<qyliss>
you don't have to do it all at once
<qyliss>
if you can get just the easy cases that's a good start
<siraben>
Heck I've seen `let lib = stdenv.lib in `
<qyliss>
wtf
<V>
there's only 46132 instances of it
<V>
ez
<Profpatsch>
A trick I’ve found is that if you use emacs and helm you can do a projectwide search with helm, then use helm-edit which opens a buffer with all matches, then use replacements on that buffer, when you are happy hit C-c C-c and it applies everything
<samueldr>
oh, and follow-up to what I said, generally it is also because "no one changed it or questioned it since then"
<V>
supersandro2000: don't worry, this is normal
<V>
as is the bikeshedding when someone tries to remove it
<V>
actually, maybe do worry
<V>
a lot
<supersandro2000>
so... I just ignore it?
<V>
what else can one do
<siraben>
Delete this line and see 10K+ packages break o.O
<samueldr>
from the commit, it looks like it was introduced before `lib` was available in any other form, so since callPackage is ~3 years younger, that makes sense
<supersandro2000>
tree wide change
<supersandro2000>
if you could automate the fixing
<V>
it's a matter of slowly trying to clean things up
<V>
supersandro2000: can I introduce you to guix
<V>
* V has been kicked from #nixos-dev
<qyliss>
supersandro2000: yeah, this is step one of trying to clean it up
<qyliss>
much easier to start with a documentation change than a 30000 line diff
<siraben>
guix using scheme sounds so nice, do they routinely write lisp programs to do metaprogramming?
<siraben>
treewide PRs equivalents
<supersandro2000>
I feel like I want some CI nitting about this
<samueldr>
isn't step 1 finding _actually why_ things are the way they are, or is it off-by-one and step 0?
<supersandro2000>
siraben: if nix used lisp I wouldn't be here
<siraben>
supersandro2000: not a fan of lisp? hehe
<supersandro2000>
I have no clue about functional programming but lisp is just .... hard
<siraben>
supersandro2000: yeah, I think what I would do to remove stdenv.lib is first identify where lib is being imported in packages and safely do a sed to replace stdenv.lib with lib
<V>
step 1 is someone innocently asking why something is like it is. step 2 is locating the commit/line where it was introduced in a large commit containing a bunch of unrelated things in 2007 because of the personal preference of the three people who used it back then. step 3 is having a huge argument about why it should be left like that
<siraben>
though, some packages break their imports by newlines >.<
<supersandro2000>
siraben: we could do that maybe in batches for 100 or 1000 packages
<siraben>
supersandro2000: right
<qyliss>
supersandro2000: CI bringing it up would be great IMO!
<samueldr>
V: step 4 is arguing about the step numbering and ordering
<qyliss>
oh good does that mean step 3 is over now :P
<supersandro2000>
do whatever you want. The Factory must grow
<V>
samueldr: there's a pair of steps for ??? and profit somewhere in here
<siraben>
Eelco in 2007: "yeah it'll be convenient"
<V>
siraben: basically
<samueldr>
V: yea, 3 ;)
<supersandro2000>
if someone asks I just say it is planned for deprecation
<V>
samueldr: okay, but the real question is whether it should be numbered from 0
<qyliss>
supersandro2000: you can link to the manual, which now explains it
<siraben>
It'd be nice to stop the flow of new stdenv.lib immediately
<qyliss>
supersandro2000: 09:26 <siraben> when unstable advances, the unstable manual will reflect the changes
pmy has quit [Quit: WeeChat 3.0]
<V>
so like, we have treewide cleanup operations every few months. how much time would it take to write a whitespace-preserving parser for performing operations like this, compared to how much time we waste on trying to manually do the equivalent for every one of these (and the inevitable breakages from human error)?
<qyliss>
so it doesn't say it yet, but it should in a few hours
<supersandro2000>
if it wouldn't be in commondoc you could actually read it
pmy has joined #nixos-dev
<V>
hey, we'd be able to read it immediately if CI happened before merge, like in any other project
pmy has quit [Client Quit]
<siraben>
V: i agree, having done some treewide PRs myself it can be painful
<V>
(which is, again, something that will take a bunch of time and energy to do anything about)
<siraben>
for 200 files I just went ahead and did it manually
<siraben>
but if it concerns thousands, well automation is needed
<V>
siraben: the most painful part about treewide PRs is how little attention they get compared to the effort involved
<siraben>
V: hm, so far I've had success in getting them attended to and merged
<V>
whereas trying to change a weird default chosen in 2007 gets immense scrutiny and bikeshedding
<V>
my hypothesis is that people just scroll through the first n pages of similar-looking diff output and go "mm, looks good"
<siraben>
This can be split up by doing sections of nixpkgs, so it's manageable
<qyliss>
siraben: are you the person who's been doing a bunch of treewide PRs recently?
<siraben>
qyliss: cmake, whitespace cleanup and (unmerged) single quoted strings?
<siraben>
that's me :P
<qyliss>
thanks for doing all that!
<qyliss>
I know it's hard, thankless work
<siraben>
no problem!
<siraben>
At the very least for now, I will look through all the packages I maintain and remove stdenv.lib
<qyliss>
you're not a committer, right? do you have one working with you who'll be able to merge when it's ready?
<qyliss>
(the single quoted strings PR)
<siraben>
I'm not a committer. I'll just ping Ericson2314 again for #108099
<qyliss>
well I'm also happy to take a final look when you think it's ready for merge :)
<siraben>
Thanks, will keep that in mind.
<V>
interested in more thoughts on building a tool for performing mass rewrites like this (à la gorename, etc)
<siraben>
I would support such efforts. It would let us do more ambitious treewide PRs and take less time to do so.
<V>
while nix isn't quite as simple to do this with as a lisp, it's still a fairly simple syntax
<qyliss>
could you use hnix for that?
<V>
I can't use haskell, so no
<siraben>
Someone mentioned hnix, in a treewide issue
<siraben>
I'm familiar with Haskell
<Profpatsch>
supersandro2000: don’t worry, there’s a movement for moving docs to markdown & the tools that rust uses
<qyliss>
that's happening right now isn't it?
<Profpatsch>
There’s an rfc which was merged which codifies the descision to move from docbook to markdown with extensions
<V>
unfortunately haskell is a theoretical language, so people who solve practical problems can't actually use it :p
<Profpatsch>
Tooling not yet decided afaik
<siraben>
qyliss: yeah, IIRC almost all of the language frameworks docs have been migrated
<siraben>
and I migrated the cross docs
<Profpatsch>
V: hnix doesn’t have a whitespace-preserving pretty printer
<qyliss>
the language framework docs were already markdown aiui
<qyliss>
what does nixpkgs-fmt use/
<siraben>
Profpatsch: aww
<V>
wellll that makes hnix effectively useless for this then
<Profpatsch>
I don’t even know how you even write something like that
<Profpatsch>
It’s a friggin hard problem
<V>
it's... not that hard?
<siraben>
nixpkgs-fmt can also produce a large diff no?
<siraben>
e.g. in the imports
<Profpatsch>
V: really?
<qyliss>
yeah but it leaves whitespace and stuff alone aiui
<Profpatsch>
I haven’t wrapped my head around it
<qyliss>
I've never used it but that's my impression from reviewing PRs formatted with it.
<siraben>
nixpkgs-fmt + some context sensitive rewrites is probably he way to go
<qyliss>
so it must have a whitespace-preserving parser that could be reused
<qyliss>
I'm not saying literally use nixpkgs-fmt for it, but it must include code that's capable of this
<Profpatsch>
It probably just does some hacks :)
<siraben>
yeah in long enough imports it splits them line by line
<V>
Profpatsch: consider how many non-AST elements there are
<V>
just whitespace and comments
<Profpatsch>
V: but like, when you insert something you want to also reflow the new code
<Profpatsch>
without having to reindent the whole file
<V>
whitespace can be broken down into newlines and indentation, comments into linewise and spanwise
<siraben>
every time I make a treewide PR I also leave the code snippets used, it's always been some sed/awk voodoo
<siraben>
with the cmake one fortunately there were only like 230 occurrences so doing it manually sufficed
<V>
Profpatsch: define "reindent"
<V>
I don't consider reformatting anything an acceptable solution here fwiw
<V>
(it would certainly help if everything was formatted consistently beforehand, though...)
<Profpatsch>
V: so what you could do is just find the problematic spans and then do simple string-replacement
<Profpatsch>
e.g. you want to parse and have rules like “if a symbol called `stdenv` is imported in the file header, any `stdenv.lib` that refers to the same symbol should be replaced by the string `lib`”
<Profpatsch>
And another rule that says “if that happens, there should be a `lib` import in the function header”
<qyliss>
the latter is going to be hard
<Profpatsch>
why? pattern match on the AST
<siraben>
without things being formatted automatically to begin with, ugh seems hard
tilpner_ has joined #nixos-dev
<Profpatsch>
if the file starts with a function header, check whether it contains `lib`, and if not insert it with a regex that amounts to s/^{/{ lib, /
<qyliss>
usual style is { stdenv, lib, <rest> }
<siraben>
quick can someone use machine learning for this :P
<qyliss>
so it would be easy enough to just insert it after stdenv I guess
<Profpatsch>
well, you can have some special rules like that if you are feeling fancey
<Profpatsch>
but totally optional
<qyliss>
well it wouldn't need to be a special rule
<Profpatsch>
at this point, it might be easier to just dump the spans and go through by hand
<qyliss>
because ~everything that uses stdenv.lib must import stdenv
<Profpatsch>
What I’m saying is that you don’t really need a whitespace-preserving parser, just a span-preserving parser
<Profpatsch>
hnix does that for example
tilpner has quit [Ping timeout: 264 seconds]
tilpner_ is now known as tilpner
<qyliss>
tbh I'm becoming less convinced you even need a parser for this
<Profpatsch>
yeah, helm-edit is probably also a viable solution
<siraben>
another thing to bikeshed, remove pkgconfig with pkg-config treewide
<Profpatsch>
I mean, better tools also lead to better refactors
<V>
<siraben> quick can someone use machine learning for this :P ← now you have an undecidable number of problems
<Profpatsch>
So it might be worth investigating if a rewriter like that could work
<V>
better stick with regex, then you only have two :p
<siraben>
sounds like an interesting theoretical problem too, because it would generalize to other languages
<Profpatsch>
Is perl-packages.nix autogenerated?
<siraben>
Also, stemming the flow of new stdenv.lib occurrences by putting a warning in ofborg and nix-hammering is an easy first step
<qyliss>
Profpatsch: don't think so
<supersandro2000>
Profpatsch: yeah I know. it is mostly done for the language docs
<V>
<qyliss> usual style is { stdenv, lib, <rest> } ← what about cases where someone inserted something between the two? what about when lib is on a different line (but still in the parameter set? what about a function that takes another function that itself takes a stdenv or lib? what about where there's both stdenv and lib in the params, but the file contains stdenv.lib regardless?
<V>
there's sooooo many places where just random find and replace can go wrong
<V>
no matter how confident you are that you've done the change correctly this time, you *have* to check over the entire thing to look for mistakes
<Profpatsch>
V: not really, you just instantiate and check whether there’s instantiation errors
<qyliss>
any of the cases you've brought up would be identified by OfBorg
<V>
(I do this kind of thing fairly regularly and still come across subtle mistakes that are only obvious afterwards)
<V>
qyliss: what if lib is already in the scope and refers to something else
<Profpatsch>
V: you mean it is aliased?
<Profpatsch>
That’s why my rule above included a check for whether it’s the same symbol
<Profpatsch>
nix can already do static checks like this
<qyliss>
if somebody assigns something other than lib to "lib" I think that's just asking for it tbh
<Profpatsch>
It’s not too hard to write a rule for if you have the AST parsed
<V>
qyliss: like in nixos? :)
<Profpatsch>
that’s the same lib
<V>
there's another lib dir
<V>
there's also paths containing the literal lib
<Profpatsch>
It’s duck-typed
<Profpatsch>
it might have a few other fields
<Profpatsch>
but the basic ones are there
<V>
there's also newScope
<V>
and extends, etc etc
<V>
so many implicit assumptions you don't know you're making until after something goes wrong
<siraben>
What's the difference between pytest and pytestCheckHook?
<qyliss>
I'd guess the latter runs the tests automatically in checkPhase
pmy has joined #nixos-dev
<siraben>
yet another area of nixpkgs that needs cleanup and consistency, the python packages
<siraben>
there's many packages that import the python package set (e.g. python3Packages) directly instead of the specific python packages it needs
<lukegb>
If I'm fixing some packages because nixpkgs-review is complaining that they're broken (but they're broken at HEAD), should I put that in a separate PR or include it in my existing one
<qyliss>
seperate
* lukegb
sad trombones
bridge[evilred] has joined #nixos-dev
srk has quit [Read error: Connection reset by peer]
justanotheruser has joined #nixos-dev
srk has joined #nixos-dev
v0|d has joined #nixos-dev
catern has joined #nixos-dev
sphalerite has quit [Quit: WeeChat 2.6]
sphalerite has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
<cole-h>
Cool, thanks. I was leaning towards master mostly because it was 2 packages that contributed to it. The _zen kernel alone was 11-100 (which I was going to merge before they created that all-inclusive zen PR).
* cole-h
runs nixpkgs-review first
<samueldr>
cole-h: all of it is churn from linuxackages_* from those linux packages updated
<samueldr>
and many, maybe most, of the linuxPackages are trivial builds
<adisbladis>
samueldr: I couldn't help myself and ordered the A5 Pro CC anyway
<samueldr>
adisbladis: move to -chat? :)
<adisbladis>
Oh, I thought this were -chat :)
<adisbladis>
Sorry
<samueldr>
n/p
<cole-h>
samueldr: Fair. Thanks.
<samueldr>
cole-h: one thing to keep in mind is whether it's expensive rebuilds or not, when looking at what seems like big numbers
<samueldr>
(and then learning what is and is not expensive)
<cole-h>
Yeah, how should I figure out what's expensive and what's not? Does Hydra list how long it takes to build a certain package?
<samueldr>
you can get that information... I don't think there's anything ready-made to get it out in a useful manner for contributors
<samueldr>
I guess that could be helpful
<infinisil>
Recently I've been noticing that there's a common pattern in Nix I haven't heard anybody talk about: Static vs dynamic configuration
<infinisil>
Basically, static config contains the values in the config files *directly*, while dynamic config only points to a *file* where the config can be read from. Some observations:
<infinisil>
Static config can't be changed at runtime without restarting/rereading the config file, while dynamic config can
<infinisil>
With Nix, static config values are usually in the /nix/store, and as such world-readable. This means only dynamic config should be used for secrets
<infinisil>
It is often desirable to be able to selectively choose which values of a config file are static and which are dynamic. Static config for persistence, but dynamic config if quick iteration is needed
<infinisil>
I think it would be really interesting to have a Nix/NixOS-native concept of static vs dynamic config
<{^_^}>
#60339 (by thoferon, 1 year ago, open): wireguard: Add peers.*.publicKeyFile as an alternative to publicKey
<infinisil>
What if *all* options implicitly had the capability to be declared either statically or dynamically
<cole-h>
qyliss++ Thanks for putting the "prefer lib over stdenv.lib" into words (and a proper guideline)
<{^_^}>
qyliss's karma got increased to 112
<infinisil>
And we had a framework to support that easily, e.g. by having a `(pkgs.formats.json {}).generate`-like concept which can compose config files at runtime consisting partially of static values, partially of dynamic ones
<ekleog>
This would sound awesome, though it also sounds like something that would require rewriting basically all modules as the configuration now needs to be written at runtime and no longer at compile-time
<infinisil>
ekleog: I'm thinking that the options declarations could choose whether they support static, dynamic, or both types
<infinisil>
Um rather `mkOption = { supportsStatic ? true, supportsDynamic ? false, type, ... }`
<infinisil>
And users might declare values as either `some.value = mkStatic "value"`, `some.value = mkDynamic "/some/file"`, or `some.value = "value"`, which is the same as the former
<infinisil>
And module authors could check whether an option is static/dynamic (if their option supports both) with e.g. `options.some.value.is{Static,Dynamic}`
<infinisil>
This might have to be a value-level thing though, because with a single `settings` option, you want to be able to declare any subpart of it as static/dynamic
<ekleog>
Sounds like a cool design then, still requires rewriting modules for them to take advantage of it but then that's something that can't really be worked around anyway :)
<infinisil>
So maybe `config.some.value ? _dynamicValue` instead, where if that's false it's a static value
<infinisil>
Yeah :)
<infinisil>
I'm not entirely convinced yet, but it's an increasingly common pattern I see, especially with sensitive data often ending up in configuration files
<ekleog>
as for mixing static and dynamic values, yeah, that'd be possible iff it's possible to define a merge strategy… or maybe decide to crash if the same value is defined in both static and dynamic configs?
<ekleog>
actually no that doesn't make sense, because sets themselves are values
<infinisil>
No need for merging, you can't set a value as both static and dynamic
<infinisil>
Well you do need to somehow combine the static and dynamic configs in the end, but that shouldn't give any conflicts
<ekleog>
Right, I meant wrt. your “this might have to be a value-level thing” to define static/dynamic on a whole option tree, but after further thought I'm with you that probably doesn't work anyway
<infinisil>
Yeah
<infinisil>
Also, this might only work for strings, because file contents are strings
<infinisil>
Although you could implement some transformers inbetween which e.g. parse an int from the fiel
<ekleog>
well, files could be JSON or similar things
<ekleog>
(though that'd mean more work for eg. “have this file be the private key")
<infinisil>
Oh yeah
<infinisil>
So maybe each option has an associated runtime parser, which transforms files into the structure that option expects
<ekleog>
Sounds reasonable, in which case supportsDynamic => dynamicKind != null
<infinisil>
dynamicKind?
<infinisil>
I'm thinking that if a value supports dynamic, and has a type != string, it needs to provide a runtime parser that can transform a string into type
<ekleog>
a name I just made up for the associated runtime parser
<infinisil>
Ah :D
<ekleog>
like supportsDynamic = true; dynamicKind = kinds.json;
<infinisil>
Oh actually that should probably by handled by the `lib.types.*` themselves
<ekleog>
which… maybe could be override-able in `mkDynamic`? though I'm not actually sure that'd bring anything so it may be pointless over-configurability
<infinisil>
Although never ind
<infinisil>
mind
<infinisil>
I guess the most basic version could just support `str`'s for simplicity
<ekleog>
actually upon further thought, making it possible to override in `mkDynamic` would allow eg. fetching the configuration from a remote source and automatically merging it in, so it may not be pointless (though whether it holds its weight is TBD)
<infinisil>
Ohh
<infinisil>
Yeah so we can have values directly, values in files, but we can further abstract that to an arbitrary command that outputs the value
<infinisil>
Then static values are `echo "the value"`, files are `cat /the/file`, and arbitrary commands are `curl https://whatev.er`
<ekleog>
oooh yeah that can be one further layer of abstraction!
<infinisil>
Interesting..
<ekleog>
unifying both use cases
<infinisil>
So maybe it should be something like `mkOption { kind = "value" / "file" / "command"; }`
<infinisil>
Um, I mean, `supportsValue`, `supportsFile` and `supportsCommand`
<infinisil>
And `mkValue` (implicit), `mkFile`, `mkCommand`
<ekleog>
hmmmmm actually `kind = "value" / "file" / "command"` made sense to me? and then `mkValue` used on `kind = "command"` would lead to `mkCommand "echo ${value}"`
<ekleog>
and `mkValue` used on `kind = "file"` would throw
<infinisil>
Yeah but options need to support multiple kinds, it can't just be a single one
<ekleog>
Hmm…? I'm thinking option implementations needs to support only one kind, so long as eg. `mkValue` automatically casts from a value to a command: for the user it's as though the option supported both kinds
<infinisil>
So that a single option can be defined as either `mkValue` (if it supportsValue), `mkFile` (if it supports etc.
<infinisil>
Ohh I see what you mean
<ekleog>
like, `mkValue foo` would be `{value = foo; command = "echo ${foo}"; }`
<ekleog>
`mkFile foo` would be `{ file = foo; command = "cat ${foo}"; }`, and `mkCommand foo` would be `{command = foo;}`
<infinisil>
Yeah that sounds good!
<infinisil>
Although problem
<ekleog>
(actually maybe `mkValue foo` could even be `{ value = foo; file = writeText "stuff" foo; command = "echo ${foo}"; }`
<infinisil>
These values would then only be available at runtime
<infinisil>
But module evaluation often uses values at eval time
<infinisil>
We'd probably want a normal value definition to be just that, `some.value = "foo"` really just defines it as foo, so that other modules can depend on that
<infinisil>
But if it's `mkFile` or `mkCommand`, `some.value = mkFile "/foo"` turns into `some.value = throw "Only known at runtime"` for other modules
<ekleog>
Hmm… is that not what I was suggesting with `mkValue`? and then `kind = "value"` would mean “use [option].value” etc.
<infinisil>
I'm a bit lost now
<infinisil>
But yeah the whole depending-on-values-at-eval-time thing becomes a bit problematic with this
<infinisil>
Because you can't rely on *any* option being known at eval time anymore, even if it has `types.str` or so
<infinisil>
And I believe that's kind of a strong assumption we rely on currently
<ekleog>
What I mean is, `let mkValue = val: { value = val; file = writeText "value" val; command = "echo '${val}'"; }; mkCommand = cmd: { value = throw "Only known later on"; file = throw "Only known later on"; command = cmd; }` etc. would IMO solve that issue
<ekleog>
But yes, it means that all options that are not `kind = "value"` can no longer be used at eval time,
<ekleog>
(but that's cosubstantial with the idea of having dynamic values)
<infinisil>
Ohh I see, yeah your mkValue and co. implementations look great
<infinisil>
Yeah, and I guess you can get very good errors in such cases
<infinisil>
And it's not like it breaks any existing workflow, it only allows more use case
<infinisil>
s
<ekleog>
right, that idea sounds great :D
<infinisil>
ekleog: One issue left is that for files/commands it needs to be defined in which context they're accessed/ran
<infinisil>
For files it matters which user accesses them, so they need appropriate permissions
<infinisil>
For commands there's the PWD, the user who runs it, whether it runs in a sandbox, etc.
<infinisil>
This could just be left to the module itself though
teto has quit [Ping timeout: 264 seconds]
<ekleog>
well, all that's outside of the realm of what the module system can do by itself, I think? because all that will be defined by the module implementations themselves
<ekleog>
(if only because runtime options mean that there needs to be a program started, and not all modules have one)
<infinisil>
Ohh, idea: To implement this, we provide a unix socket at `/run/nixos-dynamic.sock`, where each module can request the values it needs over an API
<infinisil>
On the server side we can then implement generically how these files/commands should be accessed/ran
<infinisil>
So this wouldn't have to be decided by the module itself