Are symlinks from my deriviation into the nix-store a bad practice?

My understanding is that the nix store should always be located under /nix/store, even if Nix is being ran as a non-root user. Suggested alternatives for when you must move the nix store are to either symlink /nix/store to the actual store path (not recommended but has been done) or to use a bind mount to mount the actual nix store to /nix/store, so no matter what, your logical path to the nix store is going to be /nix/store.

So with that in mind, symlinking to a file in package A from package B should be safe? There’s no chance that someone with an unusual but still considered valid setup to break this?

To be specific, here’s my use case: ros_assistant/packages/rosify_package/default.nix at b72c6e0e34c02024e6813ff3aae49f6934bc71e2 · IamTheCarl/ros_assistant · GitHub
It takes an executable from another package and wraps it in a “ROS package” so that the ROS ecosystem will acknowledge its existence at runtime.

Totally acceptable; symlinkJoin in Nixpkgs couldn’t exist otherwise.

2 Likes

Also your solution doesn’t imply anything about the location of the nix store, so whether the store is at /nix/store or not is irrelevant (which is a good thing here, as it makes your code more flexible).

To really be :nerd_face: about it I’d use lib.getExe which guards against the scenario that the binary is moved into a separate bin output, among some other nits :slight_smile:

1 Like