build-support: add new hooks

[drupol]

Hello everyone,

During the holidays, I spent some time packaging Python packages and noticed that some of them require a valid and mutable home directory to build or function properly.

Currently, the default behavior of the Nix stdenv is to set the HOME environment variable to /homeless-shelter, a read-only directory. While this approach is consistent, it can cause issues for packages that expect a writable home directory.

After performing a treewide search in nixpkgs, I found approximately 500 instances where export HOME is used (rg -c "export HOME" | wc -l) and 300 where export PATH is used (rg -c "export PATH" | wc -l). These repetitive patterns inspired me to propose a solution adhering to the DRY principle.

I created custom hooks, tmpdirAsHomeHook, which sets up a mutable home directory automatically when added to nativeBuildInputs or another appropriate place. Additionally, addBinToPath, which modifies the PATH environment variable to include bin/ if available.

I’d appreciate your feedback on this approach and have a few questions:

1. Do you think this would be a valuable addition to nixpkgs?
2. Regarding naming, I’m considering renaming tmpdirAsHomeHook to mutableHomeDirHook for better clarity. What do you think?
3. In the hooks, I use the line addEnvHooks "$targetOffset" addBinToPath. I’m not entirely confident about the best way to implement this. Could you provide some guidance?

Thanks for taking the time to review this. I look forward to hearing your thoughts and suggestions!

Best regards

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/request-for-comments-adding-two-new-hooks/58282/1

[xiaoxiangmoe]

Will this hook also be avaliable in preConfig or some thing like this?

Here is some example:

nixpkgs/pkgs/by-name/af/affine/package.nix

Line 109 in 1a685a9

export HOME="$NIX_BUILD_TOP"

nixpkgs/pkgs/by-name/af/affine/package.nix

Line 156 in 1a685a9

export HOME="$NIX_BUILD_TOP"

[drupol]

Will this hook also be avaliable in preConfig or some thing like this?

Here is some example:

nixpkgs/pkgs/by-name/af/affine/package.nix

Line 109 in 1a685a9

export HOME="$NIX_BUILD_TOP"

nixpkgs/pkgs/by-name/af/affine/package.nix

Line 156 in 1a685a9

export HOME="$NIX_BUILD_TOP"

It can actually be added to any phase hooks, so yeah.

[hsjobeki]

I like the Idea overall.
I also have two feedback Points:

• This could be two PRs.
• For my taste the amount of documentation is not enough. Especially i wouldn like to know stuff that happens internally, like what value is. $HOME set to and when?

[drupol]

• This could be two PRs.

While I'm all for splitting PR, make sure that they have a clear scope, I really don't understand why I would need to split this one. The scope is clear, even the commits are correctly split. So I'm sorry but no, I won't split this PR in two.

• For my taste the amount of documentation is not enough. Especially i wouldn like to know stuff that happens internally, like what value is. $HOME set to and when?

OK I will improve it.

[drupol]

Planning to merge this tomorrow morning, feel free to raise your voice if you believe it is a bad idea.

[K900]

I'd like to see some examples of packages helped by these hooks, at the very least.

[drupol]

I'd like to see some examples of packages helped by these hooks, at the very least.

Here's some Github search where it would be used:

• addBinToPathHook: https://github.com/search?q=repo%3ANixOS%2Fnixpkgs%20export%20PATH%3D%24out%2Fbin%3A%24PATH&type=code
• writableTmpDirAsHomeHook: https://github.com/search?q=repo%3ANixOS%2Fnixpkgs+export+HOME%3D&type=code

[K900]

This should probably at least explicitly mention it's adding $out/bin and not $sourceRoot/bin or whatever. Honestly, this is my big concern with this hook: it's not immediately obvious what exactly it does, and the thing it does comes with a bunch of weird caveats (what if there are multiple outputs? what if the binaries are in sbin? etc).

[drupol]

Thank you, I just updated the documentation. Let me know if this resolves this feedback.