files: add an option to copy files instead of linking

[rtimush]

Description

This implements #155 by adding an option to copy files to the home instead of symlinking them:

home.file.foo = { 
  text = "content";
  copy = true;
};

Although the code works for me, it needs more testing and I have some questions regarding the approach taken, so I'm creating this pull request as a draft.

The idea is that we collect a list of files that we want to copy to the home directory in the .home-manager-copy file inside home-files. The activation script looks into this file to decide whether it needs to run ln or cp. It also now compares file content with the previous generation and proceeds with an update or deletion only if the file hasn't been modified.

Open questions:

1. Is copy a good option name? Another one I can think of is link = false.
2. Is the .home-manager-copy file approach ok or it's better to keep linked and copied files separately?
3. Is there a way to write tests for the activation script?

Checklist

• [x] Code formatted with ./format.

• [x] Code tested through nix-shell --pure tests -A run.all.

• [ ] Test cases updated/added. See example.

• [x] Commit messages are formatted like

  {component}: {description}
  
  {long description}
  

  See CONTRIBUTING for more information and recent commit messages for examples.

• If this PR adds a new module

  • [ ] Added myself as module maintainer. See example.

  • [ ] Added myself and the module files to .github/CODEOWNERS.

[alexvorobiev]

Please consider adding an option to set permissions on the files. See https://github.com/rycee/home-manager/issues/322.

[colinxs]

What would it take to get this merged? I could really use this functionality :)

[stale[bot]]

Thank you for your contribution! I marked this pull request as stale due to inactivity. If this remains inactive for another 7 days, I will close this PR. Please read the relevant sections below before commenting.

If you are the original author of the PR

• GitHub sometimes doesn't notify people who commented / reviewed a PR previously, when you (force) push commits. If you have addressed the reviews you can officially ask for a review from those who commented to you or anyone else.
• If it is unfinished but you plan to finish it, please mark it as a draft.
• If you don't expect to work on it any time soon, please consider closing it with a short comment encouraging someone else to pick up your work.
• To get things rolling again, rebase the PR against the target branch and address valid comments.

If you are not the original author of the issue

• If you want to pick up the work on this PR, please create a new PR and indicate that it supercedes and closes this PR.

[stale[bot]]

Thank you for your contribution! I marked this pull request as stale due to inactivity. If this remains inactive for another 7 days, I will close this PR. Please read the relevant sections below before commenting.

If you are the original author of the PR

• GitHub sometimes doesn't notify people who commented / reviewed a PR previously, when you (force) push commits. If you have addressed the reviews you can officially ask for a review from those who commented to you or anyone else.
• If it is unfinished but you plan to finish it, please mark it as a draft.
• If you don't expect to work on it any time soon, please consider closing it with a short comment encouraging someone else to pick up your work.
• To get things rolling again, rebase the PR against the target branch and address valid comments.

If you are not the original author of the issue

• If you want to pick up the work on this PR, please create a new PR and indicate that it supercedes and closes this PR.

[alexvorobiev]

Still important to me

[minijackson]

Any update on this? What do we need in order to get this merged?

[sumnerevans]

@minijackson I think it may make sense to create a new PR which deprecate this one as it's over two years old. I think the idea is reasonable, but it probably needs the ability to set permissions as well.