Prohibit use of nixpkgs.extend from inside Nixpkgs #258
Conversation
|
I'm not sure if it makes sense to run a separate eval for each feature like this. I can't really think of any issues with just running a single strict eval to check for issues. |
|
@LnL7 better? |
|
Yeah, but maybe this should be a config option in nixpkgs. That way it's a bit less obscure to reproduce. |
|
@LnL7 I don't want people to avoid If someone is motivated to make it an option, I can review their PR. |
|
cc @Ericson2314 |
|
Having the error message inline in the command just feels a bit weird to me, but yeah it's not that complicated. @grahamc What do you think? |
There was a problem hiding this comment.
I like config option too, but this is fine for now. I've asked enough things from @roberth with this :).
|
I'm sorry to be annoying and not provide more actionable feedback sooner. This test should be applied to the evaluation which happens before and after a PR is merged. Please move the configuration to https://github.com/NixOS/ofborg/blob/ae982a2a683dfb5062ef8fb1b03bb7c3804b7e31/ofborg/src/outpaths.nix and delete the changes to the massrebuilder.rs. Aliases are tested this way because aliases are desirable for external users, but can easily rot unless they are checked regularly. This is why the check is performed once with, and once without aliases. I don't believe |
|
I'm cleaning up my open PR list. After almost four years, this has proven itself to be unimportant in many ways. If anyone disagrees, feel free to modify and use the code in any way you like. |
extendis a new function on Nixpkgs that lets users extend Nixpkgs with overlays after calling the Nixpkgs function. This makes Nixpkgs similar to package sets that were created withlib.makeExtensible.Nixpkgs should probably not start using this, because re-evaluating the Nixpkgs is somewhat expensive.
See NixOS/nixpkgs#47430 (comment)
I am not familiar with ofborg and I wasn't sure how to test this, so it is mostly cargo culted. I did test the ad-hoc overlay itself.