How to get absolute path of flake root?

How can I access flake root directory as an absolute path like /home/whiteman808/nixos_config? The issue with the following code is that projectRoot evalutes to Nix store path containing flake.nix rather than to /home/whiteman808/nixos_config where flake.nix is located.

projectRoot is set to the value of self.sourceInfo.outPath in the specialArgs at flake.nix file

{ config, projectRoot, ... }:

{
  nvim_dotfiles = [{
    name = ".config/nvim";
    source = config.lib.file.mkOutOfStoreSymlink (builtins.toString projectRoot + "/dotfiles/nvim");
  }];
}

nope. something something purity. If you want that you need to use “legacy nix” (air quotes for irony). I happily use it everyday on my own computers and revenue bearing services for $work.

That won’t work because flakes are copied to the store.
You just need to hardcode the path as a string, if you’re going to do something like this.

Or better, don’t use mkOutOfStoreSymlink.

If you are using home-manager, you can access your home directory as config.home.homeDirectory or other xdg directories with their respective config (config.xdg.cacheHome, config.xdg.stateHome, etc). In some way you will have to hardcode a subdirectory using interpolation and use that as a parameter for your link.

For me, what it worked was to use the home variable and interpolate with a .files to make the dot files location that I use. I also store the non-nix config there and make the symlinks to ~/.config from there.

Using mkOutOfStoreSymlink is very useful if you don’t want to rebuild the derivation each time you make a subtle change to, let’s say, neovim. In the end, ~/.config/nvim points to ~/.files/config/nvim.

How do you populate $HOME/.files/config directory contents?

It’s where I keep the git repository with the flake and non-nix config, I know that the directory will exist and hold the config I need.

cd ~/
git clone https://github.com/leoperegrino/.files/
cd .files/config
# directory with non-nix config to be mapped to ~/.config as needed

@leoperegrino
I’ve stolen your way to store your config files. I’m going to create separate $HOME/.files directory for all non-Nix and system config stuff.

1 Like

Nice! Happy to help.

A few remarks and pitfalls that may be useful to know:

  1. the name .files is arbitrary, you can call it whatever you want. some people use dotfiles, nixos_config as you did, or whatever. I got used to having one custom . directory so it stays hidden by default.
  2. as I mentioned the config.home.homeDirectory variable is only available if you are using home-manager, it won’t work outside of it but you may hardcode your home still.
  3. I don’t link the ~/.config entirely to ~/.files/config as that would mean that every single application would store it’s config in your git, creating a mess. I link specific configuration directories that I think that are worth keeping in their own filetype and not in a nix module
  4. if you use a git repository, you may have your git tree dirty (uncomitted) and may need to use --flake path:~/.files to avoid staging files
  5. not every link is the top directory, notice if you need the recursive = true; or not. zsh was creating zcompdump so i chose to just link the config file

What stuff I shouldn’t store in ~/.files/config? Is public git repo a good place to store stuff like qBittorrent, nicotine+, gajim, profanity configs? If the answer is no, what is the best way to reproduce them quickly?

Do I think correctly that I should avoid storing quickly varying and sensitive stuff in public git repositories?

There a lot of applications that store files in ~/.config but I don’t care to reproduce them later, so I don’t link nor version in git. The idea of ~/.files/config is for configuration that I don’t want to be in nix lang, like nvim as it would be a pain to write lua code inside a nix module, or bash, python, etc.

The matter of privacy is up to you. I would say to avoid revealing sensitive information but configuring an interface, a startup behavior or some minor stuff is not really sensitive, so it would be ok to store, I think.

As a last resort, If you want, you could make the repository private and clone it with ssh in github.