The forum is the best place to seek help for all things holochain.
There is a category dedicated to holonix discussion.
The NixOS community is active and helpful in IRC chat.
#nixos channel on
freenode.net IRC servers.
cruft on the PATH
Nix only manages the
PATH that they are aware of, e.g.
Nix shell only adds things to the
PATH by default.
If another tool adds binaries to the path then standard operating system precedence rules apply.
Known common tooling conflicts:
cargo installis known to override binaries in the nix store
rustupis known to override
nightlyversions of rust
cargo installed binaries
which to see where a binary is currently located.
For anything installed with
cargo the easiest thing is to simply delete the binary.
Any path starting with
/nix/store should be correctly managed by nix.
Nix shell tries to mitigate the risk of cargo compiling binaries to a global location by setting
$CARGO_INSTALL_ROOT to the current directory (at the time of building the shell) and places this at the start of
$PATH (for the duration of the nix shell).
rustup, depending on the nature of the conflict it may be necessary to uninstall
cargo versions or
As the nix shell mostly adds to the shell environment it is possible for existing environment state to bleed into the nix environment.
Usually this is the behaviour we want, e.g. sourcing our
.bashrc files etc. so that the shell still feels familiar.
In some cases, such as the
$PATH conflicts discussed above, we want a more aggressively isolated shell environment.
There are three levels of
nix-shell that are used commonly for everyday usage and debugging.
nix-shellis the standard isolation level
nix-shell --puremeans the environment “is almost entirely cleared” but
$DISPLAYare retained as well as
PS1="" nix-shell --pure --keep PS1is a pure environment with all environment variables cleared
If you are seeing an issue in the nix-shell that you cannot reproduce on another machine try increasing the shell isolation to debug.