New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Managing files without symlinks #257
Comments
The only way I have found to allow that is to load a mutable config from the immutable on. This requires the config file language to have include-like functionality. As an example, I'm doing this for my emacs config:
The toString will make it so that it doesn't import custom.el into an immutable /nix/store path, but rather expands to /path/to/config/custom.el. This allows you to change the custom.el file via emacs 'customize' interface, while still keeping the other part immutable. This can also be used to have a tmp.el file you include for temporary quick changes, which you can then transfer to home-manager to make them 'permanent'. |
One possibility might be to use an unsupported trick: to set the file source to a string containing the absolute path to the file that should be maintained outside the Nix store. For example,
Running I'm not sure I would recommend using this method, instead perhaps simply add an activation script that creates the symlink yourself? It would make it more explicit:
|
Being more versatile on the generated paths should be mandatory for better nixos/home-manager integration (a module should be able to be installed systemwide e.g., /etc/vimrc vs userwide ~/.vimrc). |
I agree with this point especially. |
A trick how to do this is to create some I've not done this myself yet, but I know a few public NixOS configs that work this way. |
Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting. If you are the original author of the issue
If you are not the original author of the issue
Memorandum on closing issuesIf you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort. |
I just started using home-manager, and one thing I really hope to achieve is to symlink some mutable configuration files from my home-manager/dotfiles repo into my home directory using the exact same logic home-manager uses to avoid overwriting data accidentally. It's easy enough to put |
The comment i made in #257 (comment) is outdated. The way to do it now is to use an "out of store symlink". Something like
should produce a symlink at If you remove the line from your configuration then the next switch should remove |
I've added it to the FAQ https://github.com/nix-community/home-manager/wiki/FAQ maybe we can close ? |
I didn't realize I'm okay with closing at least as far as my above usecase is concerned. |
Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting. If you are the original author of the issue
If you are not the original author of the issue
Memorandum on closing issuesIf you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort. |
see also: [Managing files without symlinks](nix-community/home-manager#257 (comment))
Can we please disable stalebot's auto-close? This makes it impossible to differentiate between unresolved and resolved issues. |
Or would you prefer that I open duplicate issues, burying all previous discussion on the same problem? |
It would be great if there was some way to set any home-manager-generated config to be "overridable" so that I could test trivial changes without being forced to rebuild. The output config would have write permissions, but running the home-manager service would "reset" them to the home-manager-generated config. This could also allow declarative management of programs that require their configs to be mutable, or programs that "prefer" it (e.g. programs with graphical configuration interfaces). |
One possible way of implementing this would be to add an option to |
Weird, |
That is expected if you use flakes, which live in the Nix store. You have to specify the absolute path on your file system, e.g. |
Thanks, that works for me. |
I have a fairly robust solution I've been using for that issue: runtimeRoot = "/path/to/my/repository";
runtimePath = path:
let
# This is the `self` that gets passed to a flake `outputs`.
rootStr = toString self;
pathStr = toString path;
in
assert lib.assertMsg
(lib.hasPrefix rootStr pathStr)
"${pathStr} does not start with ${rootStr}";
runtimeRoot + lib.removePrefix rootStr pathStr; Used like: source = mkOutOfStoreSymlink (runtimePath path); In essence you could think of |
Hey where exactly are you declaring this? I'm dealing with the same issue and want to declare this within my flake setup for my dotfiles too |
@NovaViper homeConf = host: (home-manager.lib.homeManagerConfiguration {
inherit pkgs;
extraSpecialArgs = { inherit dotfilesLib; };
modules = [ ./machines/${host}/home ];
}); Then, the { dotfilesLib, config, lib, pkgs, ... }: And call it like: source = mkOutOfStoreSymlink (dotfilesLib.runtimePath path); |
Hey thank you for clarifying! I started adding it into my flake but I'm still a little confused with how to declare it in the flake.nix file, I wrote it out like below
And where I highlighted the problematic part, it says here that the |
Either use |
In my case, |
@solson @ncfavier Thank you both! I made the changes and added it into one of my modules as a test, however I'm noticing it's not sourcing the folder correctly, making a blank source.
Definition within the modules
The repo's structure (removed a good bit of the folders listed to make the block not nearly as long)
|
It looks like your |
I tried that too but it still resulted in a blank symlink |
What does |
Here (my original comment had ran the command in the wrong directory)
|
source = config.lib.file.mkOutOfStoreSymlink (dotfilesLib.runtimePath home/novaviper/dots/PrusaSlicer/printer); This part looks wrong - the path literal should be relative to the file this code itself is in. e.g. if my For more context, note that Nix itself expands that path literal to |
Right, either use |
Ah, so |
Hey I got one more question again (hopefully this being the last!). I'm trying install Nixos onto my laptop using the config I made but I'm having trouble getting the script to start, mainly because it's running into issues with the dotfilesLib code. I have the flake inside of /mnt (which is where my system is mounted so I can install the os onto it); but the flake says |
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/neovim-config-read-only/35109/11 |
There are some configuration files that I would like to somehow manage with home-manager, but that also get changed by other tools or that you don't want to put in your home-manager config. An example of the former is the
.spacemacs
file which most people update directly from spacemacs. An example of the latter is the.ssh/config
file which I often want to augment with servers that I do not want to put into my home-manager config (because I would like to be able to make my home-manager config public). The problem is that home-manager creates symlinks to read-only files in the nix store which causes problems for these two use cases. Is there a way this issue could be worked around?The text was updated successfully, but these errors were encountered: