| Age | Commit message (Collapse) | Author |
|---|
|
list files used by `nix-channel` on its own man page
|
|
fix wording on output-addressed store objects
|
|
hashing is an implementation detail.
add references to the other terms.
|
|
e.g. nix-env -e subversion => nix-env --uninstall subversion
The aim is to make the documentation less cryptic for newcomers and the
long options are more self-documenting.
The change was made with the following script:
<https://github.com/aschmolck/convert-short-nix-opts-to-long-ones>
and sanity checked visually.
|
|
This gives some more context and should clarify why it works that way.
Also link it from the section on `NIX_USER_CONF_FILES`.
Co-authored-by: John Ericson <git@JohnEricson.me>
|
|
|
|
Document user files of nix
|
|
|
|
`/etc/bash.bashrc` is backed up as `/etc/bash.bashrc.backup-before-nix`,
but since other changes might have been introduced in the meantime we can't
just tell the user to revert.
|
|
At least on Ubuntu 22.04, these files are not created as part of a multi-
user installation.
|
|
|
|
At least on Ubuntu 22.04, the Nix installer creates
`/etc/profile.d/nix.sh`, not `/etc/profile/nix.sh`.
|
|
`sudo systemctl disable nix-daemon.socket nix-daemon.service` removes these
files already.
|
|
|
|
|
|
|
|
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|
add anchor to `builtins.derivation` and list some built-in functions that are
exposed in the global scope.
I decided not to list everything, because we probably don't want to
encourage people using them that way.
|
|
- add anchor to `builtins`
- add type information
- reword description of `builtins` to offer more information concisely
|
|
|
|
|
|
* doc rendering: add functions to scope explicitly
this especially helps beginners with code readability, since the origin
of names is always immediately visible.
|
|
it's probably better not to show the manifest file documentation in the
command-specific pages, because these are implementation details that are not really practically useful.
this means no additional hassle for building the manual, but clutters
the table of contents a bit.
|
|
placed in a subsection of the binary install, the instructions are hard
to find. putting them in a separate page that is shown in the table of
contents should make it easier for users to find what they need when
they need it.
|
|
|
|
|
|
otherwise the headings won't match at the point where they are included.
this is a bit hacky and brittle, but works for now.
|
|
adapt to the example listing
|
|
|
|
|
|
this is to make it consistent everywhere
|
|
|
|
|
|
Fixes broken link for `Nix database` anchor in the Glossary page of the
Nix manual.
|
|
remove incorrect reference to `NIX_PATH` documentation
|
|
|
|
Co-authored-by: John Ericson <git@JohnEricson.me>
|
|
Fix #8162
The test is changed to compare `nlohmann::json` values, not strings of dumped
JSON, which allows us to format things more nicely.
|
|
Use it everywhere it could be also.
|
|
Use long options instead of short ones in the "quick start"
|
|
- Create a glossary entry for experimental features.
- Have the man page experimental feature notice link `nix-commmand`.
(Eventually this should be programmed, based on whether the command is
experimental, and if so what experimental feature does it depend on.)
- Document which installables depend on which experimental features.
I tried to use the same style (bold warning and block quote) that the
top of the man page uses.
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|
|
|
Documentation: list experimental features in manual
|
|
As requested by @fricklerhandwerk.
|
|
|
|
|
|
This function returns true or false depending on whether the Nix client
is trusted or not. Mostly relevant when speaking to a remote store with
a daemon.
We include this information in `nix ping store` and `nix doctor`
Co-Authored-By: John Ericson <John.Ericson@Obsidian.Systems>
|
|
They are put in the manual separate pages under the new overarching
description of experimental features.
The settings page just lists the valid experimental feature names (so
people know what a valid setting entry looks like), with links to those
pages. It doesn't attempt to describe each experimental feature as that
is too much information for the configuration settings section.
|
|
|
|
Add a page explaining what “experimental features” are, when and how they should be used
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
Co-authored-by: John Ericson <John.Ericson@Obsidian.Systems>
|
