<
matthewcroughan>
samueldr: Can't find a description of what it does hmm
<
matthewcroughan>
is this it?
<
samueldr>
yes this is it
<
matthewcroughan>
samueldr: do I need a separate attrset PER function execution?
<
matthewcroughan>
robotnixConfigurations = lib.genAttrs { "pyxis" = "foo"; "bacon" = "bar"; }
<
samueldr>
nix-repl> lib.genAttrs [ "a" "b" ] (name: "x${name}")
<
samueldr>
{ a = "xa"; b = "xb"; }
<
samueldr>
> I want the function to be applied to all members of this list
<
matthewcroughan>
yes, I want the function robotnixConfigurations to be applied to all members of this list
<
samueldr>
if you had a list of device names, you could use `lib.genAttrs thatList thatFunction`
<
samueldr>
if you have pairs, then maybe you want mapAttrs
<
samueldr>
your requirements are a bit unclear
<
matthewcroughan>
samueldr: nix-repl> lib.genAttrs [ "pyxis" "bacon" ] (name: x)
<
matthewcroughan>
{ bacon = "helloworld"; pyxis = "helloworld"; }
<
matthewcroughan>
So, that works, but this is not what I want.
<
matthewcroughan>
this is more or less what I want, bear with me ;D
<
matthewcroughan>
Do you see the issue?
<
matthewcroughan>
6-9, I don't want to have to write robotnix.lib.robotnixSystem each time
<
matthewcroughan>
bully me*
<
matthewcroughan>
samueldr: I do not have a list of device names, I have a list of device definitions that even includes the imports.
<
danielrf[m]>
if all devices configs live under a path like ./hosts/${name}
<
danielrf[m]>
(previous gists untested)
<
matthewcroughan>
danielrf[m]: how does lib get put in there? If I'm defining it in my flake?
<
matthewcroughan>
lib is inaccessible
<
danielrf[m]>
You'd probably have to add nixpkgs as a flake input
<
matthewcroughan>
it already is
<
matthewcroughan>
yet it's inaccessible
<
matthewcroughan>
I've added it verbatim to this flake :D
<
danielrf[m]>
It looks like it's under nixpkgs.lib
<
matthewcroughan>
robotnixConfigurations = inputs.nixpkgs.lib.mapAttrs (n: v: inputs.robotnix.lib.robotnixSystem v) {
<
matthewcroughan>
looks like this
<
matthewcroughan>
that seems to work
<
danielrf[m]>
The "inputs." shouldn't be necessary
<
matthewcroughan>
It seems to be :D
<
matthewcroughan>
Wonder why
<
matthewcroughan>
inputs.robotnix is required
<
matthewcroughan>
the stuff in the ()
<
matthewcroughan>
robotnixConfigurations = nixpkgs.lib.mapAttrs (n: v: inputs.robotnix.lib.robotnixSystem v) {
<
matthewcroughan>
this works, for example
<
danielrf[m]>
hey if it works :)
<
matthewcroughan>
so what is n? And what is v?
<
matthewcroughan>
You may help me understand what lib.mapAttrs is doing if you can describe this :D
<
matthewcroughan>
n is robotnixConfigurations, right
<
danielrf[m]>
n is "name", v is "value"
<
matthewcroughan>
error: flake output attribute 'robotnixConfigurations.pyxis' is not a derivation
<
matthewcroughan>
hmm
<
matthewcroughan>
Can't build it, so how would you build your template?
<
danielrf[m]>
How are you trying to build it?
<
matthewcroughan>
tried to nix build .#robotnixConfigurations.pyxis
<
danielrf[m]>
try: nix build .#robotnixConfigurations.pyxis.img
<
matthewcroughan>
yup, totally works.
<
matthewcroughan>
Is there a way to just add that into the libAttrs?
<
danielrf[m]>
the mapAttrs you mean?
<
matthewcroughan>
Sorry, yes :)
<
danielrf[m]>
Sure, you could do (n: v: (inputs.nixpkgs.lib.robotnixSystem v).img)
<
danielrf[m]>
However, that's picking a particular output associated with the robotnix build
<
danielrf[m]>
and what happens if you later want to build an OTA based on the robotnix configuration?
<
danielrf[m]>
Like, before you could just run `nix build .#robotnixConfigurations.pyxis.ota`
<
danielrf[m]>
but if you add `.img` to your mapAttrs then you'd lose easy access to the other robotnix outputs
<
matthewcroughan>
Nice clean commit for anyone who wants an example.
<
matthewcroughan>
Ah, I see what you're saying about ota/img now.
<
danielrf[m]>
nice :)
<
matthewcroughan>
I don't think it tab completes though.
<
matthewcroughan>
I've rebased it without .img, for that reason
<
matthewcroughan>
it does tab complete
<
matthewcroughan>
Actually, rebased it again to get the commit message wrapping properly, whoops.