Change:
I'm planning to use nix as a package manager for my development toolchain, but not do the actual development in nix, is that a supported use case? I've hit some issues and have been sending in PRs to resolve them, but looking into it more the issues I've been hitting might have been derivations just working as intended. explains that library derivations in Nix only work when used in a nix environment, be it nix-shell or within nixpkgs. Is the same true for all development derivations, for example compilers and build tools? Examples: ++ doesn't work outside of nix-shell on darwin, but it does on linux, and I'm not sure which of the two is correct (). creates compiler wrappers to handle the way flags from dependencies are propagated in nixpkgs, but those wrappers are unnecessary when using the compilers from profiles. the bazel derivation is a script that wraps bazel to make it use clang and java from nix, instead of resolving it from the caller's , so that it can be used from within nixpkgs, but it results in a bazel that doesn't function correctly when installed. If existing development derivations are meant to be only used in a nix environment, would it be ok to add new derivations for use outside of a nix environment?
Nixpkgs do not explicitly support C++ compilers outside Nix environment, but this is a valuable use case and it would be great if you could work towards it.
It won't be helpful if there's no convention around it, how would someone find out which specific compilers work outside a Nix environment and which don't?
Either the default compilers will work (, ), or people will discover the new compilers (e.g. ) in the list of packages, in Nixpkgs issues, on the wiki, on IRC etc.
I have managed to work around this issue by creating wrappers for the compilers tailored to the specific use cases I have. It works very well, and it seems it's what others are doing as well. I'll close this issue since it's not relevant anymore.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Discussion:
<ins> { cabal, binary, executablePath, filepath, ghcPaths, ioStorage , time, xdgBasedir }: cabal.mkDerivation (self: { pname = "dyre"; version = "0.8.11"; sha256 = "0sg5csshznbbyvq72s4sps7bkjlkfxiwcy4i3ip83lrxjw1msvr8"; buildDepends = [ binary executablePath filepath ghcPaths ioStorage time xdgBasedir ]; meta = { homepage = "http://github.com/willdonnelly/dyre"; description = "Dynamic reconfiguration in Haskell"; license = self.stdenv.lib.licenses.bsd3; platforms = self.ghc.meta.platforms; }; }) </ins>

<ins> { cabal, filepath }: cabal.mkDerivation (self: { pname = "xdg-basedir"; version = "0.2.2"; sha256 = "0azlzaxp2dn4l1nr7shsxah2magk1szf6fx0mv75az00qsjw6qg4"; buildDepends = [ filepath ]; meta = { homepage = "http://github.com/willdonnelly/xdg-basedir"; description = "A basic implementation of the XDG Base Directory specification"; license = self.stdenv.lib.licenses.bsd3; platforms = self.ghc.meta.platforms; }; }) </ins>

dualTree = callPackage ../development/libraries/haskell/dual-tree {}; <ins> dyre = callPackage ../development/libraries/haskell/dyre {}; </ins> editDistance = callPackage ../development/libraries/haskell/edit-distance {}; editline = callPackage ../development/libraries/haskell/editline {};

X11Xft = callPackage ../development/libraries/haskell/X11-xft {}; <ins> xdgBasedir = callPackage ../development/libraries/haskell/xdg-basedir {}; </ins> xdot = callPackage ../development/libraries/haskell/xdot { polyparse = self.polyparse_1_7; };