I think we want to ensure that all new items in headers are documented,
and the documentation on modified items is kept up to date.
It will take a while to document the backlog of undocumented things, but
we can at least ensure that new items don't extend that backlog.
Was probably an overlook of when the tests were first added, but that
now messes-up with the `nix-channel --update` that happens down the line
(and can't access the network since we're inside a Nix build)
otherwise the order of found `.md` files will influence if `@docroot@`
is replaced before them being included, which may mess up relative
links.
the weirdest thing about it is that the mess-up happens
deterministically on macOS, but deterministically doesn't happen on
Linux!
Documentation on "classic" commands with many sub-commands are
notoriously hard to discover due to lack of overview and anchor links.
Additionally the information on common options and environment variables
is not accessible offline in man pages, and therefore often overlooked
by readers.
With this change, each sub-command of nix-store and nix-env gets its
own page in the manual (listed in the table of contents), and each own
man page.
Also, man pages for each subcommand now (again) list common options
and environment variables. While this makes each page quite long and
some common parameters don't apply, this should still make it easier
to navigate as that additional information was not accessible on the
command line at all.
It is now possible to run 'nix-store --<subcommand> --help` to display
help pages for the given subcommand.
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
This fixes the issue that `nix-build`, without experimental feature
'nix-command' enabled, recommends the experimental CLI `nix log` to view
build logs. Now it'll recommend the stable `nix-store -l` CLI instead.
Fixes https://github.com/NixOS/nix/issues/8118
in order to make the development process more transparent for everyone,
all pull requests should go through the triage process before getting
merged.
this ensures that all team members are aware of what is going on, and
that rationale for decisions is kept track of in the meeting notes for
posterity. (ideally all that should go into the commit history, but this
is a more invasive process change that needs further deliberation.)
having all team members take at least a brief but conscious look at each
change may also help with keeping our quality standards, as more
reviewers are more likely to remind each other of our shared values.
