Change:
# pkgWithCombinedDepsDevDrv :: Derivation pkgWithCombinedDepsDevDrv = pkgWithCombinedDeps.envFunc { inherit withHoogle; }; <del> mkDerivationArgs = builtins.removeAttrs args [ "packages" "withHoogle" "doBenchmark" ]; </del> <ins> mkDerivationArgs = builtins.removeAttrs args [ "genericBuilderArgsModifier" "packages" "withHoogle" "doBenchmark" ]; </ins> in pkgWithCombinedDepsDevDrv.overrideAttrs (old: mkDerivationArgs // { nativeBuildInputs = old.nativeBuildInputs ++ mkDerivationArgs.nativeBuildInputs or [];

Discussion:
Describe the bug The Haskell build framework does not appear to appropriately source Haskell packages in the environment when for the entire Haskell package set except a single packages (in this case, the package being developed. See for a reproduction; specific areas of interest are as follows: To Reproduce Steps to reproduce the behavior: the following: is neither built by Nix, nor included in the packages displayed by the call to calling from within the shell will attempt to download dependencies from Hackage , one can apply the following patch and observe the following: is built by Nix however it is still not displayed by the call to calling still attempts to download the package from Hackage, even though we observed that it was compiled by Nix <details<summarypatch</summary<p</p</detailsExpected behavior Nix's Haskell build framework should support the following behavior: disabling all tests in a package set while also selectively enabling tests for a subset of packages as desired appropriately sourcing the transitive dependency tree of all enabled components in a Haskell project within the environment's GHC Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --ping as we spoke about this on Slack. Metadata NOTE: My personal Nix configuration is fairly involved; at the time of writing I've tested this with:
cc who I think touched the stuff recently and may be able to spot the bug sooner than I'll be able to take a good look at this.
I tried an earlier nixpkgs commit (, which was some arbitrary 20.03 release from February) along with GHC 8.6.5 (since that's what was in-tree at the time). looks like it still doesn't display the transitive test dependencies and still tries to download from Hackage, so maybe I'm just misunderstanding how this is all meant to work together.
Heart racing Basically the culprit is this line This uses the mkDerivation which you've overridden here: which forces the tests to be disabled, in this case for the fake package which has constructed.
A potential fix is having something which respects flags which have been explicitly set in your mkDerivation override, for example flipping the arguments to : and setting in the call to in . This is pretty nasty though because the is still being ignored. Not to mention that this doesn't stop anyone else from bumping into this.

I think it's quite safe to always pass to in as test dependencies won't make it into if that package has had tests disabled. I've not tested this or anything so it could all be wrong!
Looking at similar code for ( by has to be specifically requested by the user. Why isn't always turned on like I suggest is above, would it make any difference to always enable it?
I sent a PR with an example of getting this to work: I left some commentary there.
Thanks for the suggestion with the order of overriding . That turned out to make the difference. I agree this is pretty tricky. This is a good question. I think it depends on how we want to be used. If we want to be able to explicitly ignore deps for benchmarks and tests, then we really need to have the option to disable/enable and . If we want to be dumb and just take all the transitive deps of its packages, then we could just always set and to . But in this case, the user would always have to do something like this override to control whether tests and benchmarks are enabled for all the packages in the Haskell package set. I don't think there is a "correct" answer here, we just need to think about what would be easier for the most end-users.
But the test dependencies (same for bench depends) are included in the arguments to mkDerivation iff doCheck (or doBench) is true: I do see the rationale for disabling this though, but I think there's no harm in enabling these both by default as they do nothing when nothing in the package set requests test or bench depends. This of course ignores other effects of and , but I don't think any of those (like enabling the checkPhase) affect the derivation.
I'm sorry, I think we might be talking past each other. In my previous post (), I was trying to explain our two choices between providing arguments to to disable/enable tests and benchmarks, or just always having enable tests and benchmarks on the virtual Haskell package it creates. I think you're talking here about the following: Assuming we do provide arguments to to disable/enable tests and benchmarks (currently we only have the argument for benchmarks), do we let the default value be or ? I agree with you that defaulting them both to make sense, for the reasons you give.

I defaulted to so that the hash wouldn't change for anyone currently using . However, I don't feel strongly about this. We could change it to true. Ideally we would also add a Release Note about this.
I agree with that all! Sorry for the communication mishap! I had not considered this, makes sense!
defaulting these to does feel slightly weird because: the action we want to tell isn't "enable the tests and benchmarks" but instead "make sure you include every dependency I give you". Setting and to accomplishes this, but only because of the indirect action. Perhaps an alternative would be to, after zipping the attrs, just pile all the dependencies together in ? (Again it's not quite the right thing to do though, but maybe a little better?)
First off thanks for getting around to this so quickly, and I appreciate all of the elucidation in this thread (and elsewhere)! Having slept on it, I think what I really want (and what might be more generally useful) is closer to what is saying (). Specifically, it seems like there should be some attributes for the fake package that's used to construct the shell environment which allow us to include these sorts of other dependencies irrespective to (etc.). It seems reasonable that local developers would want Nix to manage all of their dependencies (i.e. , , and shouldn't have to access Hackage at all). However it also seems reasonable that the compilation/inclusion of these dependencies in the 's exposed isn't coupled with whether or not the test/bench suite is actually run when the environment is constructed. It's often very useful to drop into a (or even plain ) session to muck around with some dependencies that are used within the project, even if I don't intend to build it at all. The counterargument to the behavior described above is that changing is cache-invalidating, and I imagine most people are either pulling from the Nix binary cache or some hosted build cache fed from a CI process (which can probably run test/benchmark suites without issue). Does that make sense, and do you know if there's a way that the Haskell build framework could be updated to support this kind of exposure?

Make sure to pass it on down the line :+1: This flag passed to could also disable the building phases, as this derivation is only useful for an interactive shell, and the phases don't make much sense (especially with multiple packages in )
Whoops, sorry for not following up on this . It sounds like the change tried out in addresses the core issue here, and it seems like this would be generally useful for Nix's Haskell package expressions. If that's the case, what do you think the best path forward towards getting something like this merged into proper would be? Ideally, it would be nice if this could be backported to but I don't know anything about what that might involve (although I'd be willing to assist with this, as it's affecting a few projects at work). If that's not the case, then is there anything that needs to be explored before something like it could be merged? I'd also be willing to help here (even if it's just messing around with a branch that has this change and trying to poke at the ergonomics of the API). Thanks, especially for the quick response to my initial issue and for all of the discussion. Hope y'all had a happy new year!
Do you want to try sending cdepillabout as a PR to nixpkgs? It would be great if you could add a little documentation about what is going on, and maybe give some motivation in a comment for why someone would want to use the additional option. Once we merge it into the branch, I imagine it would be fine to also backport to 20.09 (assuming it wouldn't break anything for most people).