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.
While this is created to match `himalaya`’s configuration API, this
could easly be reused for other programs that consume the email module
by concatination the strings.
The previous version linked the file into home, then sourced that. Since
nothing else expects that file to be there, this is unnecessary.
Additionally, doing so made it impossible to test a built config without
switching, e.g. using `XDG_CONFIG_HOME=… nvim` or `nvim -u`. This
remedies that, at least for this particular reference.
To test this, change from asserting contents of the config file to
actually starting nvim, outputting sentinel values, and then asserting
their values are present. This way it’s tested that nvim loaded the
config, rather than that some config is in a specific place.
This is all in one commit as the test, as written now, would not have
worked before since the previously hard-coded home path was not an
actual file in the test environment.
