Change:
</listitem> <listitem> <para> <ins> Haskell <varname>env</varname> and <varname>shellFor</varname> dev shell environments now organized dependencies the same way as regular builds. In particular, rather than receiving all the different lists of dependencies master together as one big lists, and then partitioning into Haskell and non-Hakell dependencies, they work from the original many different dependency parameters and don't need to algorithmically partition anything. </para> <para> This means that if you incorrectly categorize a dependency, e.g. non-Haskell library dependency as a <varname>buildDepends</varname> or run-time Haskell dependency as a <varname>setupDepends</varname>, whereas things would have worked before they may not work now. </para> </listitem> <listitem> <para> </ins> The <package>gcc-snapshot</package>-package has been removed. It's marked as broken for &gt;2 years and used to point to a fairly old snapshot  from the <package>gcc7</package>-branch. </para>

Discussion:
Describe the bug Haskell derivations: behaviour of in regards to changed in 20.03. Projects relying on the old behaviour will break. A number of Haskell projects I work on use to make test dependencies and build tools available in the environment when invoking . PR changed the implementation of the attribute which subtly changes the effect has. Using instead is a workaround for this (or possibly the function I should've been using all along). I believe I was using incorrectly but it is difficult to be sure, because the expected usage of and is not documented (AFAIK). Using In 19.09, ( ++ ) produces: In 20.03, ( ++ ) produces: is present in 19.09 but not 20.03. Interestingly, is not present in either. If we instead use : we get the following results in 19.09: and in 20.03: and are present in both. So, using in and does exactly what I want (with the version being a bit cleaner). The "fix" for this issue might just be to document the intended usage of: , , , , , , , and a bit more clearly (if not already - sorry, I couldn't find any). To Reproduce Steps to reproduce the behavior: (). it and cd into the directory. the following commands in a : where the invocation is one of: number of convenience make targets are available too. Expected behavior I expected to make and available in my shell.
cc as the author of , (who I think wrote the original version), and (who did an extensive review) We should probably have documentation for this, or at the very least a note in the release notes for 20.03.
Side question: how did you print the result of in the context of your actual package?
So I created a small nix file something like: Then:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I think this looks correct to me. Nevermind the build-time vs run-time distinctions I am usually harping about. The most important thing to understand for this is just like the regular generic builder always did, the now respects the different type of inputs parameters stating Haskell vs non-Haskell, and uses that instead of the predicate it used to sift between the combination of everything before.

tl;dr and items always don't become in env, and instead get passed on to the , while and do become . On the build-time deps side, including the tools, whether or not something was written in Haskell doesn't matter, so they all become .