You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, if we invoke ghcWithPackages from within that shell/environment, we get the wrong packages available, e.g.
~$ nix-shell -p 'haskellPackages.ghcWithPackages (h: [ h.containers ])'
[nix-shell:~]$ nix-shell -p 'haskellPackages.ghcWithPackages (h: [ h.text ])'
\[\][nix-shell:~]$\[\] echo -e 'import Data.Text\nmain = putStrLn "hello world"' | runhaskell
/run/user/1000/runghcXXXX1804289383846930886.hs:1:8:
Could not find module ‘Data.Text’
Perhaps you meant
Data.Set (from containers-0.5.6.2@conta_2C3ZI8RgPO2LBMidXKTvIU)
Use -v to see a list of the files searched for.
This is because the outer GHC appears first in PATH:
We can avoid this by using --pure on the inner nix-shell, but that may prevent some functionality from working; in particular, we can no longer call nix-shell; either because it's not available, or if we specified it as a dependency we get an error:
$ nix-shell --pure -p nix
[nix-shell:~]$ nix-shell -p which
error: Nix database directory ‘/nix/var/nix/db’ is not writable: Permission denied
This problem with the environment not appearing at the head of PATH seem to be the cause of some errors I've been running into with some Haskell applications. Hopefully those more familiar with Nix, buildEnv, etc. could figure out a way to ensure this directly.
In the mean time, I've figured out a hacky way to fix the PATH after the fact. First we distinguish between the environments by name, rather than by hash; ghcWithPackages inherits its name from the relevant ghc package, which is why both environments above were called xxxx-ghc-7.10.3.
After stumbling on the comments for #6575 I tried using lib.setName to set their names, as per #6575 (comment) but this doesn't work; e.g.
The next step is to look up these names in PATH and prepend the correct one to the front, which is easy enough if the name of the environment is in $NAME:
With this workaround, I've able to create nested Haskell environments where each "layer" has access to the packages it needs.
I admit that it's rather an obscure use-case, so my main reason to report it is to help anyone encountering such issues in the future. If it doesn't seem worth fixing then I don't mind continuing to use my workaround.
For a little context, I was testing an application which uses nix-shell internally to resolve Haskell dependencies, since they're only known at run-time. It runs fine standalone, but trying to invoke it as a sub-process from other Haskell programs (e.g. for tests or benchmarks) runs into this problem.
I'm running NixOS from the nixos-unstable channel:
$ nixos-version
16.03pre75806.77f8f35 (Emu)
The text was updated successfully, but these errors were encountered:
For the record, it is possible to work around this, by using pure shells and setting NIX_PATH and NIX_REMOTE appropriately. Whether that's a good idea or not is another question ;)
We can use
haskellPackages.ghcWithPackages
to get an instance of GHC with particular packages available, e.g.However, if we invoke
ghcWithPackages
from within that shell/environment, we get the wrong packages available, e.g.This is because the outer GHC appears first in
PATH
:We can avoid this by using
--pure
on the innernix-shell
, but that may prevent some functionality from working; in particular, we can no longer callnix-shell
; either because it's not available, or if we specified it as a dependency we get an error:This problem with the environment not appearing at the head of
PATH
seem to be the cause of some errors I've been running into with some Haskell applications. Hopefully those more familiar with Nix,buildEnv
, etc. could figure out a way to ensure this directly.In the mean time, I've figured out a hacky way to fix the
PATH
after the fact. First we distinguish between the environments by name, rather than by hash;ghcWithPackages
inherits its name from the relevantghc
package, which is why both environments above were calledxxxx-ghc-7.10.3
.After stumbling on the comments for #6575 I tried using
lib.setName
to set their names, as per #6575 (comment) but this doesn't work; e.g.Next I tried using
overrideDerivation
as per #6575 (comment) which seems to work, but causes GHC to rebuild from source, which I didn't want:My current solution is to use
buildEnv
:The next step is to look up these names in
PATH
and prepend the correct one to the front, which is easy enough if the name of the environment is in$NAME
:With this workaround, I've able to create nested Haskell environments where each "layer" has access to the packages it needs.
I admit that it's rather an obscure use-case, so my main reason to report it is to help anyone encountering such issues in the future. If it doesn't seem worth fixing then I don't mind continuing to use my workaround.
For a little context, I was testing an application which uses
nix-shell
internally to resolve Haskell dependencies, since they're only known at run-time. It runs fine standalone, but trying to invoke it as a sub-process from other Haskell programs (e.g. for tests or benchmarks) runs into this problem.I'm running NixOS from the
nixos-unstable
channel:The text was updated successfully, but these errors were encountered: