Assigning to `programs.neovim.extraLuaPackages` a function taking a lua package set as input
and returning a list of packages, as described in the documentation,
threw an error because the rest of the code assumed that the value was always a plain list.
Using `lib.types.coercedTo`, we can accept such functions, as per the documentation,
as well as plain lists, which we then convert to a function ignoring its input argument.
We print a warning when a plain list is assigned, since the function
form is preferred, as it ensures that the right lua package set is used.
For the lua packages, we also get the lua package set from the
finalPackage, to make sure that we are always using the same package set
as the actual unwrapped neovim package being built.
For `programs.neovim.extraPythonPackages` I did the same.
I updated the test case so that we test both ways of setting these options.
This enables nushell integration by default for direnv, similar to
bash/zsh/fish. The slightly verbose way of setting this is to ensure
that peoples' existing nushell configuration isn't overwritten, only
appended to, as would be the case if we just used the integration
example from the nushell docs:
https://www.nushell.sh/cookbook/direnv.htmlCloses#3520
When building from a flake, `nix build` hides the build output by
default, with a `-L`/`--print-build-logs` option to show it. Pass this
option along from `home-manager` if the user provides it.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Previously the nushell module did not differentiate between Linux and
Darwin when deciding where to place config files, whereas nushell
does. This commit fixes that.
The default value for `xsession.windowManager.herbstluftwm.tags` is an
empty list, but the config file uses `builtins.head` on it, which causes
an error upon evaluation. With this change the tags configuration is
skipped if the list is empty.
Depending on DHCP settings you might end up with different output from
running `hostname`. Eg, your local hostname is `mylaptop`, and your
home router is configured with a local domain of `.hoome.arpa`. In
this case:
$ hostname
mylaptop.home.arpa
$ hostname -s
mylaptop
If you then go to cafe which has its router configured with `.lan` as
its local domain. Then, if your DHCP settings accept the local domain
from the router,
$ hostname
myalaptop.lan
$ hostname -s
mylaptop
With the pre-existing behaviour, if you had a
`"me@mylaptop.home.arpa"` entry in `outputs.homeConfigurations`,
running `home-manager switch` would fail:
$ home-manager switch
error: flake 'git+file:///home/me/.config/nixpkgs' does not provide
attribute 'packages.aarch64-darwin.homeConfigurations."me".activationPackage',
'legacyPackages.aarch64-darwin.homeConfigurations."me".activationPackage'
or 'homeConfigurations."me".activationPackage'
After this commit, you can put configuration in a `"me@mylaptop"`
entry in `outputs.homeConfigurations`, and everything will work on
either network.
The previous variant used IFD to generate the `JAVA_HOME` variable and relied on internal hooks of the `java` package, this failed for a user cross compiling their configuration.
This PR changes that and uses the `home` attribute, as documented in the very last sentence of the https://nixos.org/manual/nixpkgs/stable/#sec-language-java chapter.
The old trigger would actually never cause a restart since the path
doesn't change. With this change the trigger is now using the actual
configuration path in the Nix store, which depends on the content.
