-
-
Notifications
You must be signed in to change notification settings - Fork 13.7k
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
documentation.nixos.enable: Default to false #83871
base: master
Are you sure you want to change the base?
Conversation
Generation of configuration.nix is hugely expensive. For example, evaluation of the configuration of my laptop takes 3.97s realtime with documentation.nixos.enable set to 'true', but 2.42s with it set to 'false'. In other words, documentation generation accounts for 39% of evaluation time. Given that the docs are readily available online (and in a more convenient form than 'man configuration.nix'), it seems better to disable them by default.
I wonder what it'd take to optionally disable generating docs for |
I don't know... for interactively used systems, one or two seconds of evaluation sounds quite cheap to me. For other systems it sounds better disabled by default. I'm not sure how to well differentiate among these, but if you agreed, we could at least approximate (say, those with graphical display managers). |
It might be also interesting how much memory it saves. Especially for low-memory devices. We should enable it on our installation images though because people might need to lookup documentation though. |
Yes, though in those cases you probably want to completely avoid evaluating (on that machine). |
On my laptop it saves 2.3s/+60% (with documentation 5.916s, without 3.650s) evaluation time. |
I am always using |
Not in my case, as I'll add this option to my personal defaults if this gets merged ;-) For a quick search |
An alternative solution is to have a the manual build from a pre-evaluated xml dump. This one could be periodically updated in nixpkgs. The only disadvantage is that you won't have options generated for your own modules. |
Yes, that would a middle route. I expect the xml could easily live in a separate repo. |
The other disadvantage of that approach is that we would need to sync this up ideally with channel updates or we get out-of-date configuration... |
It could be done by a bot regularly... the main question is whether it's all worth it :-) (i.e. perhaps most people are OK with the two ways we have already) |
@grahamc Yes, it would be nice to keep the other manpages. |
Could we enable it for the installer profiles? |
documentation should not be an opt-in if you want users to opt-out, make it more visible in documentation with a note about its time savings perhaps a better way of making this kind of stuff visible, but probably a lot of work, could be to |
Hello, I'm a bot and I thank you in the name of the community for your contributions. Nixpkgs is a busy repository, and unfortunately sometimes PRs get left behind for too long. Nevertheless, we'd like to help committers reach the PRs that are still important. This PR has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. If this is still important to you and you'd like to remove the stale label, we ask that you leave a comment. Your comment can be as simple as "still important to me". But there's a bit more you can do: If you received an approval by an unprivileged maintainer and you are just waiting for a merge, you can @ mention someone with merge permissions and ask them to help. You might be able to find someone relevant by using Git blame on the relevant files, or via GitHub's web interface. You can see if someone's a member of the nixpkgs-committers team, by hovering with the mouse over their username on the web interface, or by searching them directly on the list. If your PR wasn't reviewed at all, it might help to find someone who's perhaps a user of the package or module you are changing, or alternatively, ask once more for a review by the maintainer of the package/module this is about. If you don't know any, you can use Git blame on the relevant files, or GitHub's web interface to find someone who touched the relevant files in the past. If your PR has had reviews and nevertheless got stale, make sure you've responded to all of the reviewer's requests / questions. Usually when PR authors show responsibility and dedication, reviewers (privileged or not) show dedication as well. If you've pushed a change, it's possible the reviewer wasn't notified about your push via email, so you can always officially request them for a review, or just @ mention them and say you've addressed their comments. Lastly, you can always ask for help at our Discourse Forum, or more specifically, at this thread or at #nixos' IRC channel. |
I have documentation disabled on all of my arm devices as single-threaded I wonder if this gets better with the new CommonMark tooling. |
This change fails ofborg and I tend to always run man when I need to know something instead of searching online to make sure I have the right manual version. |
Not completely against it, but I think it should go to the |
I marked this as stale due to inactivity. → More info |
still relevant. |
I marked this as stale due to inactivity. → More info |
is this still relevant with lazy options collection (which has massively decreased eval time)? |
This also removed the help pages for nixos tools like |
Generation of the manual is hugely expensive. For example, evaluation of the configuration of my laptop takes 3.97s realtime with
documentation.nixos.enable
set totrue
, but 2.42s with it set tofalse
. In other words, documentation generation accounts for 39% of evaluation time.Given that the docs are readily available online (and in a more convenient form than
man configuration.nix
), it seems better to disable them by default.Motivation for this change
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)