| Age | Commit message (Collapse) | Author |
|---|
|
also slightly reword the purpose statement to introduce (and explain)
derivations right away.
|
|
Expanding tests and docs relating to deleting profiles
|
|
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|
Introduce what substituters "are" in the configuration option entry.
Remove arbitrary line breaks for easier editing in the future.
Link glossary some more.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Co-authored-by: John Ericson <git@JohnEricson.me>
|
|
nix actually needs c++20 now
|
|
Add `nix-channel --list-generations`
|
|
|
|
packages and configurations are not really a concept in Nix or the Nix language. the idea of transforming files into other files clearly captures what it's all about, and the new phrasing should make the term "derivation" more obvious both in terms of meaning and origin.
|
|
document identifier syntax for attribute sets
|
|
|
|
Add support to --list-generations
as another way to say
nix-env --profile /nix/var/nix/profiles/per-user/$USER/channels --list-generations
the way we did for nix-channel --rollback [generation id]
|
|
|
|
|
|
update documentation according to release notes
|
|
document `builtins.currentTime`
|
|
distributed-builds.md: Clarify warning ssh access requirements
|
|
this makes future reviews easier as it reduces diff noise
|
|
|
|
|
|
The primop `builtins.replaceStrings` currently always strictly evaluates the
replacement strings, however time and space are wasted for their computation
if the corresponding pattern do not occur in the input string. This commit
makes the evaluation of the replacement strings lazy by deferring their
evaluation to when the corresponding pattern are matched and memoize the result
for efficient retrieval on subsequent matches.
The testcases for replaceStrings was updated to check for lazy evaluation
of the replacements. A note was also added in the release notes to
document the behavior change.
|
|
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.
|
|
use consistent wording everywhere.
add some details on the configuration option documentation.
|
|
|
|
it's more likely for readers to find it right there.
this also slightly rewords examples to make them stand out better.
in the long run there probably needs to be a dedicated section on formal syntax, and better highlighting of examples.
|
|
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.
|
|
|
|
|
