home-manager: add a way to set the priority of the home-manager-path package

[e-nikolov]

Description

Partially addresses #2995

Adds the --priority flag to the home-manager switch command and the meta.priority module option to allow overriding the default priority of the installed home-manager-path package in the user profile.

One common use-case is in single-user installations of nix in containers or WSL that have no native systemd. Currently it is very difficult to configure home-manager to manage the nix installation. The issue is that the original nix is installed with the default priority of 5 and then home-manager will try to install its own nix with a priority of 5 which will fail due to the priority conflict.

For nix profile install, there is only a way to set the priority while installing a package, and no way to update the priority of an existing package, other than uninstalling it and reinstalling it with a new priority. This is rather difficult when the conflicting package is nix itself. You have to install a second nix with a lower priority, delete the original nix and then install home-manager, configure it to manage a 3rd nix and then delete the second nix.

With the functionality in this PR, it makes this problem easier to solve by installing home-manager packages with a higher priority and then deleting the original nix.

This PR works well for nix profile install, but in the case of nix-env, I think there is no way to atomically install a package and set its priority with the same command. It's only possible to install the package via nix-env --install and then update its priority via nix-env --set-flag priority. If there is already a conflicting package, nix-env --install will fail and we won't be able to reach the nix-env --set-flag part.

In any case, this functionality is more useful in the nix profile case because it does not have a way to update the priority of an existing package, while with nix-env you could lower the priority of the old nix before installing home-manager to avoid the conflict.

I am not sure how to write a proper test that verifies the priority of the resulting package after the nix profile install. Are there any existing tests that do something similar?

Checklist

• Change is backwards compatible.

• Code formatted with ./format.

• Code tested through nix-shell --pure tests -A run.all or nix develop --ignore-environment .#all using Flakes.

• Test cases updated/added. See example.

• 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.

Maintainer CC

@rycee

[stale]

Thank you for your contribution! I marked this pull request as stale due to inactivity. 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 PR

• 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.

[drupol]

Would this fix #5258 ?

[stale]

Thank you for your contribution! I marked this pull request as stale due to inactivity. 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 PR

• 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.