Change:
inherit lib config stdenv; }) mkDerivation; <del> # For convenience, bring in the library functions in lib/ so # packages don't have to do that themselves. inherit lib; </del> <ins> # Slated for deprecation in 21.11 lib = builtins.trace ( "Warning: `stdenv.lib` is deprecated and will be removed in the next release." + " Please use `pkgs.lib` instead." + " For more information see https://github.com/NixOS/nixpkgs/issues/108938") lib; </ins> inherit fetchurlBoot;

Discussion:
Carry over discussion from IRC #nixos-dev and . Inspired by the doc change in recommending top-level usage of over , we want to reduce confusion for newcomers and unnecessary complexity by making the canonical way to access the Nix library. We may still want to keep to not break external code, and place a or similar at its definition site. There are over files where occurs at least once. Beyond splitting this change across multiple PRs, in what ways can the change be automated? Pinging
In the short term, we could add this check in ofbrorg and , and update any examples in the documentation to reduce new usage of .
Don't forget things like and .
Ah. So 45K occurrences across 11.8K files.
toplevel is done
the xorg dep generator also doesn’t put it in its output anymore
trewide rewrite in
doc changes in
Graph of occurrences over time:
Nice! What scripts did you use to generate it?
There's a source code link now :)
Found another large source of s. Fixing cabal2nix should remove around 24k occurrences in .
Status report
Just found out that counts stuff like as well, so
Is it ok to rewrite to ?
That's the lib output of , so no.
an easy way to find out is to evaluate both in
Subfolders of with <10 changes needed in PR
Around + replacements out of 30k+ are concentrated in - should be trivial to regenerate the file with the new desired contents.
I'm working on it but it's a bit more complicated than I anticipated.
What problems are you running into?
Part of code generation of cabal2nix is in an external dependency, so I had to open two PRs. The dependency is itself on Hackage, so we may have to wait until the change propagates to Stackage LTS and then Nixpkgs, unless peti will use an override or something: I'm not familiar with the cabal2nix workflow.
I think the haskell-updates are mostly done from a local checkout of cabal2nix, so it depends mostly on what version peter is using. You can also probably just ask him, he is generally available for such things on his .
could you help here?
The Haskell infrastructure has switched to the new style with commit . It will land in this Friday.

I have also updated the generator code and released new versions to Hackage, so I guess the Haskell infrastructure can be considered done.
Thank you
More accurate regex: (the one above captures stuff like
When is merged, this will be the result Three Nix files remain that use directly.
The last usages of it can be found by commenting out where it is inherited in .
I just got this warning while doing a , but it doesn't give me any info as to which derivations are at fault. Is there any way we could improve the message to identify culprits?
With , you should get a hard error which will allow you to use . Or you can update Nixpkgs, since it has been removed in