-
-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
Tracking issue: remove overuses of with lib;
#208242
Comments
rg inside Emacs
|
A prime example of over used with is https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/x11/desktop-managers/plasma5.nix#L282-L285 It is unclear what package is using which with and most packages could come from multiple and some even from all. Those kinds of usages must be cleared up. The problem is not when with is used in meta where it is very local and only covering a few lines. I am completely against changing those treewide. The examples given on nixos.dev are also not great to say it diplomatic. For example the following code snippet is backwards and is making the code longer and harder to understand especially for beginners which only start to learn the language. I know that I can explain the first line to a beginner and they will understand it without much trouble. The suggested alternative I would need to lookup first and then I would expect a beginner to have some trouble and a harder time to understand what is happening. If I show them both I would expect them to ask why not the first one is used and my answer would be "I don't get it either why this was changed, makes no sense to me 🤷🏼" # instead of:
buildInputs = with pkgs; [ curl jq ];
# try this instead:
buildInputs = builtins.attrValues {
inherit (pkgs) curl jq;
};
Inheriting function from lib near the top of a file is more busy work for me and not improving much. Why do I need to keep track which functions from lib are used? Why do I need to scroll up and manually update the list? Why not just use You could argue that is the same for packages but packages have an actual build and/or runtime cost in comparison to lib functions which are, except evaluation time, free. Also mixing different package sets from the same ecosystem can be dangerous like multiple python versions. Mixing functions from lib worst case increases evaluation time and if code logic is not changed, can't break a package. |
Hi!
edit: i should read Sandros comment more carefully as it already asks that question. |
I am not happy with such uses because it is easy to extrapolate them.
Day after day you youself justify many seemingly equivalent pieces of code as "do this the other way because it will not break splicing", or any other obscure reference to Nixpkgs internals. Do you think a beginner that is trying to package a Python library will understand why there are seemingly equivalent appearances of I could buy the "shorter and easier to understand" idea right before the "beginner" part. Hell, day after day I pick beginners failing to understanding the CONTRIBUTING guide! Definitely we have way more problems with beginners than longer codes. Just to be sure: I am not being elitistic about the beginners above (sometimes I am, but not here and now). It is completely the reverse - our documentation is still a bit far from beginner-friendliness.
I always link the nix.dev anti patterns guide - a NixOS-backed reference. About the example below
The aforementioned "beginners" you cited write, without hesitation, code like
This is a typical example of a beginner code trying to be merged into Nixpkgs. Certainly, the Nixpkgs way below:
is what I would call longer and harder to understand especially for beginners which only start to learn the language.
I explained this a hundred times in a row: that was a draft - a draft, subject to incremental, future polishing. |
Then the nixpkgs manual itself should be changed; as it is, it liberally uses The nix.dev antipatterns guide warns against using |
It is not as if I disagree with this. Indeed I planned to touch on documentation after the code, but I changed my mind. I will modify the docs asap EDIT: #293767 |
This removes "with lib", which advances NixOS#208242 a bit, and cleans up a few formatting nits found by nixfmt.
Issue description
There are many overused
with lib;
expressions on Nixpkgs, especially on NixOS modules. As explained in this link, it is a problematic anti-pattern.Steps to reproduce
rg "with lib;"
or anything like that.Technical details
"x86_64-linux"
Linux 5.15.83, NixOS, 23.05 (Stoat), 23.05.20221222.7ba7b45
yes
yes
nix-env (Nix) 2.12.0
/nix/var/nix/profiles/per-user/root/channels/nixos
References
https://nix.dev/anti-patterns/language#with-attrset-expression
NixOS/nix#490
#305642
The text was updated successfully, but these errors were encountered: