-
Notifications
You must be signed in to change notification settings - Fork 247
Fix the way ExeDependency is handled #1036
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
Conversation
See input-output-hk/nix-tools#101 We should look up hsPkgs.${pkg-name}.components.exe.${component-name} instead of including the package as a dependency. Adding `hsPkgs.${pkg-name}` a tool it is not clear which executable in the package `haskell.nix` should choose. Haskell.nix did not deal with this well and in fact it could lead to `nix-shell` crashing. For instance using `shellFor` to make a shell for building `haskell-language-server` with `cabal build` crashed as a dependency on `ghcide` the executable (by the `ghcide-bench` executable) caused infinite recursion. Allowing `ghcide-bench` to correctly depend just on `components.exes.ghcide` fixes this.
bors try |
tryTimed out. |
bors try |
bors try- |
bors try |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... so we need a new nix-tools for this, and if people cross streams, this will fail, right?
I don't think it will be any more broken than it is now though. |
fair point |
tryTimed out. |
bors try |
bors try- |
bors try |
bors try- |
bors try |
tryBuild failed: |
bors try |
tryBuild succeeded: |
See input-output-hk/nix-tools#101 We should look up hsPkgs.${pkg-name}.components.exe.${component-name} instead of including the package as a dependency. Adding `hsPkgs.${pkg-name}` a tool it is not clear which executable in the package `haskell.nix` should choose. Haskell.nix did not deal with this well and in fact it could lead to `nix-shell` crashing. For instance using `shellFor` to make a shell for building `haskell-language-server` with `cabal build` crashed as a dependency on `ghcide` the executable (by the `ghcide-bench` executable) caused infinite recursion. Allowing `ghcide-bench` to correctly depend just on `components.exes.ghcide` fixes this. This PR also includes: * Updated materialized files built with the new nix-tools and latest index-state * Small update to GHCJS (pins happy) to fix issue that showed up when the materialization was updated * A fix for the infinite recursion issue when updating materialized files (by adding ghc-boot-packages-unchecked). * Performance fix for shellFor (checks just the names of component derivations when filtering).
See input-output-hk/nix-tools#101
We should look up hsPkgs.${pkg-name}.components.exe.${component-name}
instead of including the package as a dependency.
Adding
hsPkgs.${pkg-name}
a tool it is not clear which executable in the packagehaskell.nix
should choose.Haskell.nix did not deal with this well and in fact it could lead to
nix-shell
crashing. For instance usingshellFor
to make a shell for buildinghaskell-language-server
withcabal build
crashed as a dependency onghcide
the executable (by theghcide-bench
executable) caused infinite recursion. Allowingghcide-bench
to correctly depend just oncomponents.exes.ghcide
fixes this.