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
shellFor requires test dependencies even when tests are disabled #993
Comments
Concrete case when this came up:
|
hamishmack
added a commit
that referenced
this issue
Jul 23, 2021
…omponents and pick latest packages (#1166) This change updates to the latest `nix-tools` to get the following fixes (there are 3 PRs in nix-tools, but just the one in haskell.nix to avoid having to update the materialized files multiple times): ## Better support for source repository packages * input-output-hk/nix-tools#107 Currently these are replaced by the `cabalProject` functions with regular `packages:` before running cabal configure. Cabal does not treat these the same (the setting of `tests:` and `benchmarks:` in the `cabal.project` file): * The plan found by `cabalProject` may not match the one used when running `cabal`. * The performance of the solver may not be consistent with running `cabal`. This change replaces `source-repository-package` with another `source-repository-package` pointing at a minimal git repo. ## Only include planned components * input-output-hk/nix-tools#108 Only the components in the `plan.json` are now included in the haskell.nix cabal projects. This avoids missing dependencies attempting to build components that were not in the plan. Should fix #993. ## Pick latest packages * input-output-hk/nix-tools#109 When the same package occurs more than once in a `plan.json` file (perhaps because it is needed both by the project itself and by one of the `setup` dependencies or `build-tool-dependencies` of the project) the latest version will now be the one picked by haskell.nix. This is a work around for a common issue with `cabal-doctest` when cross compiling to windows (an old version of Win32 is used even if a newer one was required by the projects `constraints`).
booniepepper
pushed a commit
to booniepepper/haskell.nix
that referenced
this issue
Feb 4, 2022
…omponents and pick latest packages (input-output-hk#1166) This change updates to the latest `nix-tools` to get the following fixes (there are 3 PRs in nix-tools, but just the one in haskell.nix to avoid having to update the materialized files multiple times): ## Better support for source repository packages * input-output-hk/nix-tools#107 Currently these are replaced by the `cabalProject` functions with regular `packages:` before running cabal configure. Cabal does not treat these the same (the setting of `tests:` and `benchmarks:` in the `cabal.project` file): * The plan found by `cabalProject` may not match the one used when running `cabal`. * The performance of the solver may not be consistent with running `cabal`. This change replaces `source-repository-package` with another `source-repository-package` pointing at a minimal git repo. ## Only include planned components * input-output-hk/nix-tools#108 Only the components in the `plan.json` are now included in the haskell.nix cabal projects. This avoids missing dependencies attempting to build components that were not in the plan. Should fix input-output-hk#993. ## Pick latest packages * input-output-hk/nix-tools#109 When the same package occurs more than once in a `plan.json` file (perhaps because it is needed both by the project itself and by one of the `setup` dependencies or `build-tool-dependencies` of the project) the latest version will now be the one picked by haskell.nix. This is a work around for a common issue with `cabal-doctest` when cross compiling to windows (an old version of Win32 is used even if a newer one was required by the projects `constraints`).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Suppose test component T depends on package A, but none of the other components do. Then if we put
tests: False
incabal.project
, we will generate a plan that doesn't contain A. However, the test component still exists, and doesn't seem to have any metadata saying it can't be built. This means:nix-build
ing T will fail, because A is not in the package set.shellFor
will fail, since it tries to get all the dependencies for all the components including T.I'm not sure what the right thing to do here is, maybe we need to set
buildable = false
on components which are disabled by cabal?The text was updated successfully, but these errors were encountered: