-
-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GHC can't find the unordered-containers
library
#491
Comments
I'm unsure of the root cause of this, but I suspect that we'll find differences in the environments created by the two different invocations. Does I'm afraid I don't have the time immediately to dig into this issue (nor do I have nearly enough haskell knowledge), but hopefully this gives you enough information to go digging. If you have more questions, please don't hesitate to ask. I'm happy to consult as I find time. |
Hm, I do not use a flake, just a In case it helps, I ran |
Without more information about how you're invoking What is in your Here is the spot where I suspect that there's some difference in either how you should be calling |
I am experiencing the same issue, using Running One thing I noticed was that my starship prompt calls the direnv environment |
@f1rstlady it's likely the case that cabal & ghc being picked is different in the shell & outside. Try running nix-shell --run "which ghc; which cabal" and check outside which ghc; which cabal if @paj0sch this could be related to how nixpkgs' haskell infra works, cabal is free to choose a different plan if it knows there are new packages available in it's index and if the constraints allow it, check CABAL_DIR=/tmp cabal run to not use the available index in your |
@pranaysashank running your cabal command makes cabal fail in the |
I don't have ghc and cabal installed in my user environment, this is not the issue. |
@paj0sch did you check |
@pranaysashank Yes, the package is not listed in the direnv shell, while being listed in the nix-shell shell. |
Edit: See the next comment for the fix for this original issue @paj0sch I can reproduce the original issue and it seems to be related to how let
pkgs = import <nixpkgs> {};
haskellPackagesWithMine = pkgs.haskellPackages.override {
overrides = self: super: {
nix-direnv-with-unorder-containers = self.callCabal2nix "nix-direnv-with-unordered-containers" ./. {};
};
};
in haskellPackagesWithMine.shellFor {
packages = p: [ p.nix-direnv-with-unorder-containers ]; # Add ghc packages you want to develop here
buildInputs = [ pkgs.cabal-install ] # optional: Add any packages you want in the shell here
} @bbenne10 do you happen to have any insights into why direnv doesn't get the same environment as nix-shell, here's how |
@paj0sch @f1rstlady Apparently you need to set - build = pkgs.haskellPackages.developPackage { root = ./.; };
+ build = pkgs.haskellPackages.developPackage { root = ./.; returnShellEnv = true; }; |
@pranaysashank Oh wow, what an oversight. Thank you very much, the option works as expected, fixing the issue for me. |
Thanks, @pranaysashank, for your effort! Looking at |
@f1rstlady: Are you referring to Line 117 of that diff? If so, we didn't explicitly remove the variable, but rather only stopped shadowing it in nix-direnv. It should still be set to whatever value the underlying invocation sets it to. I thought that this might be an unnoticed regression in how we invoke non-flake workflows, so I gave it a test but without the GHC toolchain: In if ! has nix_direnv_version || ! nix_direnv_version 3.0.4; then
source_url "https://github.com/raw/nix-community/nix-direnv/3.0.4/direnvrc" "sha256-DzlYZ33mWF/Gs8DDeyjr8mnVmQGx7ASYqA5WlxwvBG4="
fi
use nix In shell.nix (or default.nix - I tested both to see if there was a difference based on filename): let
nixpkgs = builtins.fetchTarball {
url = "https://github.com/NixOS/nixpkgs/archive/3c80acabe4eef35d8662733c7e058907fa33a65d.tar.gz";
sha256 = "1q7yfx235bxi3nfg0zm51sjl1akwlilvkhx6p1mf5rwrilb0iln3";
};
pkgs = import nixpkgs { config = {}; };
in pkgs.mkShell {
packages = builtins.attrValues {
inherit (pkgs) hello;
};
} I then simply did
I do not fully understand the implications of these results yet. |
@bbenne10 It looks like the variable should be present before the echo "$(nix print-dev-env --profile /tmp/tt --impure --file ./default.nix)" > without-env echo "$(IN_NIX_SHELL=impure nix print-dev-env --profile /tmp/tt --impure --file ./default.nix)" > with-env Diffing them both |
Thanks for tracking this down. I see now how this problem was introduced in the above referenced commit. I am still not entirely sure quite what to do in nix-direnv's code though. I can see that we might desire to explicitly set Looking over nixpkgs, I can see that there's a number of features gated by |
perhaps it should be nix's |
I think that question gets thorny in the nix ecosystem right now. If we're supporting "old" workflows (that is - I'm going to say - for now - that nix-direnv needs to figure out a way to handle both new/experimental and old/stable workflows equally. (Note that my stance on this in another project would be different. For instance, we don't have this exact problem in flake-env, since there I explicitly don't support this particular code path - there are advantages and disadvantages to "quickly" supporting new workflows :P ). I will work up a commit that simply sets |
I just opened #498 to hopefully address this issue. Would y'all mind testing it out and letting me know if it resolves this particular issue for you? |
How am I supposed to test this? I added the following overlay:
Afterwards, I rebuilt my home-manager config. This resulted in:
|
In a project specific
This uses direnv's built-in support for fetching URLs and sourcing the result. I'm not sure why your overlay failed, but this avoids doing the resholve build at all and should work fine (If it doesn't, please report back!) |
@bbenne10 I tested it and it fixes the issue |
GH-491: Explictly set IN_NIX_SHELL to more closely mimic nix-shell execution
I just merged #498, resolving this issue. We will have to tag a new release to get it into nixos. I'll have a look at the changeset that we've accrued between 3.0.4 and here and see if we should cut a new release. For now, please use the |
We can probably make a patch release for 24.05 as well. |
You were faster at doing what I meant to do today - index what we had and cut a point release. Thank you! I don't think backporting for 24.05 will be an issue, but wanted to note that we weren't there yet (probably could have been clearer - hadn't yet had my coffee ☕) |
After this was fixed, I encountered a different error:
where the current working directory is Investigating the diff between nix-shell's and nix-direnv's environments shows that it is caused by
Do you have an idea what might have caused this difference? |
@f1rstlady spaces in directory are not supported by nix, See |
@pranaysashank Didn't know. Thanks! |
Hello, I encountered a strange issue when developing a Haskell project. I used to enter my dev environment with
nix-shell
, everything worked fine. But nix-direnv seems to mess up the environment such that GHC can't find Haskell'sunordered-containers
library that was installed by nix.Minimal working example
I debugged my environment and could reduce the problem to the following minimal working example. A trivial Haskell project set up by cabal:
And a
default.nix
file that builds the project throughhaskellPackages.developPackage
, which in turn reads the*.cabal
file and installs the specified dependencies:Expected behaviour
The command in question is
cabal exec -- ghc --print-libdir
. In the originalnix-shell
, it succeds:$ nix-shell --run cabal exec -- ghc --print-libdir -Q /nix/store/x0pn53qh4mnkvfwgm7qm6n19wgk3fyr6-ghc-9.6.5-with-packages/lib/ghc-9.6.5/lib
Actual behaviour
However, in the environment provided by nix-direnv, it fails:
Interestingly, if you remove the
unordered-containers
dependency from the Cabal file, it gives the expected output.I'm aware that this issue is quite specfic since it involves not only nix-direnv but
nixpkgs.haskellPackages.developPackage
, cabal and the unordered-containers Haskell library. I would be glad if you could give me some hint.The text was updated successfully, but these errors were encountered: