How to find some shell plugin that I want to source in my `~/.zshrc`?

Help
1

As I’m trying to move my config over to home-manager step by step, I realised a few days ago, that when I have some shell plugin which provides an “entrypoint” which is meant to be sourced into the shell, then I have no clue how to actually find that entrypoint without doing some very hefty extra lifting…

Currently I’m roughly doing this:

  1. Create a derivation which pulls in the actual files, as in https://gitlab.com/NobbZ/nix-home-manager-dotfiles/blob/c14cb4c2b9cbf3f1e1c67a8e6290283322078a18/nix/asdf-vm.nix#L4-17
  2. Create another derivation which has the first in buildInputs and creates a shell script that prints some commands to run as in https://gitlab.com/NobbZ/nix-home-manager-dotfiles/blob/c14cb4c2b9cbf3f1e1c67a8e6290283322078a18/nix/asdf-vm.nix#L19-49
  3. Add the latter to home.packages.
  4. Add another file into a special folder of my setup which gets sourced automatically from my .zshrc which always follows the pattern if which $script 2>&1 >/dev/null; then eval $($scrip); fi

Is there some simpler way to find the installation path of the first derivation, such that I can reduce the indirections and just source from the first path without that much of clutter?

2

I had a look at your setup and maybe I’m missing something fundamental but wouldn’t

home.file.".zsh/boot/asdf.zsh".text = ''
  . ${sources.asdf}/asdf.sh
  . ${sources.asdf}/completions/asdf.bash
'';

suffice?

1 Like
3

This totally seems to work, and its so obvious to do it like this!

Thank you!

Though I can not accept your reply as the solution?

PS: Is there some way in home-manager to create/use configurable modules?

4

HM uses the NixOS modules library so the Writing NixOS Modules section applies. You can look at existing modules in HM for inspiration, the programs.feh module is nice and simple.

5

I’m pretty sure it complained about not knowing imports key when I tried it for the last time…

Will try it again. Thanks!

6

When you specify options and config fields then the imports goes on the top-level. So

{ ... }:

{
  imports = [ … ];
  options = { … };
  config = { … };
}

and not

{ ... }:

{
  options = { … };
  config = {
    imports = [ … ];
    …
  };
}
7

Well, I had it at the toplevel.

The start was just a home.nix with the following content (not in the repos history):

{pkgs, ...}:

{
  imports = [];
  programs.home-manager.enable = true;
}

And it failed with an error regarding imports, though I can neither remember, nor reproduce the error message.

8

Thanks!

The module is picked up and seen, though I can’t use it, as it seems to not use “my” pkgs but the “systems”, wothout the overlays I specified declaritively in my home-manager config.

9

You can’t accept the reply as the solution because this topic wasn’t put in the “Learn” category.

1 Like
10

That sounds a bit odd. If you use the pkgs argument that is given to the module then it should be extended by the overlays you have specified in Home Manager’s nixpkgs.overlays option. Note, any overlays you have in ~/.config/nixpkgs/config.nix or ~/.config/nixpkgs/overlays will be ignored inside the HM configuration.

11

I did not have that.

I created a pkgs in another file and assumed it would be used everywhere. I already learnt that this is not true, and even more sad, that there seems no way to pin down the nixpkgs to a certain commit via home-manager as well…

In a perfect world, there were no need to do nix-channels --update anymore, but instead bump the commit-sha and checksum in the sources.json. More tedious for sure, but reproducable between machines.

After I learned that this won’t work, I just used nixpkgs.overlays for now, and it worked exactly once, then I updated the channels and since then I have the problem described and discussed in Home-Manager doesn't work anymore after `nix-channels --update`