<clever>
a module is a function that looks like this:
<clever>
it should be in the nixos module docs
<clever>
a module always returns a set containing 3 keys, options, imports, and config
<clever>
modules are always in the form of { config, lib, ... }:
<clever>
whatever is calling the function, is passing it things
<clever>
matthewcroughan: the only way to get things into a nix file, is for the file to return a function, then you call that function and pass it things
<clever>
matthewcroughan: basically, every nix file is evaluated in its own private scope, it never gets any context from whatever imported it
<clever>
i just throw code at github and ignore the license file, lol
<clever>
sphalerite: ah, that explains why i thought it was readline
<clever>
sphalerite: ah, has it changed? i thought it did
<clever>
jumper149: i did C-x C-r while strace'ing the repl, and it didnt read any cfg files
<clever>
jumper149: it might also need the program to tell readline to read the cfg file, do the docs say anything about that?
<clever>
jumper149: i believe its using libreadline, so check if that has env vars to switch its mode
<clever>
there was probably a nixos.regalium and a nixoops.regalium
<clever>
config.nix*
<clever>
Regalium: but every channel also respects config.txt, so both channels are going to have the same override
<clever>
Regalium: without -A, it will search every channel for the given pkg
<clever>
nix-env -iA nixos.regalium, will use your exact override, from a channel named nixos in --list
<clever>
-i will search for any package with the right .name, while -iA tells it exactly what to use
<clever>
Regalium: you probably still want to use -iA
<clever>
like, foo = self.foo.override....;
<clever>
Regalium: does your override use the same attribute name for the replacement?
<clever>
Regalium: what does `nix-channel --list` and `sudo nix-channel --list` report?
<clever>
matthewcroughan: the 1st only accepts a set, which must contain the listed keys, the 2nd can accept any type
<clever>
previously, it was a function that took 2 args, which can also be thought of as a function that takes 1 arg, and returns a second function
<clever>
nope, in both cases you where defining a function
<clever>
the module system will then supply that set to you
<clever>
and that argument must be a set, containing the listed keys
<clever>
matthewcroughan: your defining a function, that takes a single argument
<clever>
probably
<clever>
that has a collection of custom modules, that are entirely self-contained, not nixos or HM
<clever>
its internals of how lib.evalModules works
<clever>
now you have 2 extra args, self and inputs
<clever>
look closer, i added a 2nd line
<clever>
did you add the .args.self?
<clever>
and i just added self, so you can now do { config, pkgs, self, ... }:
<clever>
since your not passing it a self anymore
<clever>
you have to modify matthew/default.nix to remove the self: now
<clever>
or a path
<clever>
and a module can either be a set or a function
<clever>
matthewcroughan: the matthew key, can either be a list of HM modules, or a naked HM module
<clever>
like so
<clever>
the way you already have it working
<clever>
matthewcroughan: i think passing self thru like that is the simplest option, it already works, and gives you access to a few things
<clever>
matthewcroughan: as i said: 2020-12-21 10:43:56 < clever> matthewcroughan: any time you do `{ foo, bar }:` your just creating a function that accepts "one argument", that argument MUST be a set, which contains a .foo and .bar attr
<clever>
matthewcroughan: but you could also do `{ inputs, ... }: { config, lib, pkgs, ... }:`
<clever>
matthewcroughan: that self.inputs will only exist, if the thing calling it, passes it a set containing inputs
<clever>
that doesnt make any sense
<clever>
and you would still have to set _module.args.self somewhere
<clever>
and it only works one layer deep, so it would be `{ config, lib, pkgs, self, ... }:`
<clever>
matthewcroughan: any time you do `{ foo, bar }:` your just creating a function that accepts "one argument", that argument MUST be a set, which contains a .foo and .bar attr
<clever>
`{ config, lib, pkgs, self.inputs, ... }:` is not valid, you cant have a . in an arg name
<clever>
so you get your own return value, as an argument
<clever>
and then it will pass the final merged result back into every module
<clever>
it will then merge the return value from every module (according to the merge rules defined in options)
<clever>
it will run every module, recursively (checking each for an imports attr)
<clever>
lib.evalModules is practically magic
<clever>
and you must somehow set _module.args.inputs
<clever>
which will pass the _module.args to every module
<clever>
that function is fed to lib.evalModules
<clever>
matthewcroughan: any time you import a file, that file is evaluated in an entirely clean scope, with no variables leaking over, at all
<clever>
so the `users/default.nix` is effectively just doing `matthew = { config, lib, pkgs, inputs, ... }: ...`
<clever>
and returns a 2nd function
<clever>
this file, then puts that "self" into a new variable, also called self
<clever>
the "self" that it received as an input, from flake.nix
<clever>
that will import the other default.nix, and then treat it as a function, passing it 1 arg
<clever>
matthew = import ./matthew self; # pass 'self' in order to allow ./users/default.nix -> ./users/matthew/default.nix to access ${self}, to provide a path relative to flake.nix.
<clever>
matthewcroughan: note here, you are passing the flake "self" to matthew/default.nix
<clever>
matthew = import ./matthew self; # pass 'self' in order to allow ./users/default.nix -> ./users/matthew/default.nix to access ${self}, to provide a path relative to flake.nix.
<clever>
yeah, i dont use flakes much yet
<clever>
yeah
<clever>
modules and imports can take files, lib.evalModules will import for you
<clever>
also, dont use import there, that makes the error messages worse
<clever>
modules = [
<clever>
(import ./hosts/t480/configuration.nix)
<clever>
i dont use home-manager, so i dont know the asnwer exactly
<clever>
how do you then pass home-manager an HM module, from nixos?
<clever>
matthewcroughan: line 28-32 is a nixos module