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:
Do you think this would be a valuable addition to nixpkgs?
Regarding naming, I’m considering renaming tmpdirAsHomeHook to mutableHomeDirHook for better clarity. What do you think?
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!
For the home, this is a good idea. Though finding out that this is the issue you are having is probably worse most of the time than the actual fix. This can manifest in so many subtle ways for things to go wrong. I’m wondering why HOME is, by default, set to a location that breaks a lot of expectations many applications have about HOME. Wouldn’t it be better to not set it at all if it’s not wanted to have a HOME during build? But maybe that breaks even more stuff and this is a matter of “lesser evil”.
Looking at how PATH is manipulated, there seem to be quite a few variants. Indeed, plenty seem to add $out/bin but there is also others that seem to add bin-directories in other locations. Not sure if that is something that we should cover.
On the topic of discoverability, it’s probably more intuitive to search for export.*HOME than guess that such a hook exists and search for it. On the other hand, if you did that after your change is implemented everywhere, this search would make you find your hook, so it’s probably good.
Overall, I think the HOME one is very good, the PATH one could do with some customization, e.g., the option to add more paths.
As of today, the current behaviour is to set HOME by default in a immutable directory. My proposal is to just update that env. variable to a mutable directory when the hook is added only.
Yes, but this is a bit out of scope of what I’m trying to achieve here. We could potentially think about this afterwards.
Indeed, this is something I already noticed, however I haven’t found yet a way to parametrize a hook, do you know how I could do that?
Random uninformed guess - deliberately to make it trigger errors, so it’s obvious that the package build is doing this? And to make the maintainer properly investigate the implications??
