https://github.com/NixOS/nixpkgs/pull/89885 ensures that fetches are
done securely (i.e. without `--insecure`) when the `hash` parameter is one of
the four special "fake" hashes. However the manual was not updated in that PR.
This commit updates the manual to account for the already-merged changes from
that PR.
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Allows restricting patches to a specific subdirectory, à la
`git diff --relative=subdir`.
This cannot be done (cleanly) currently because the `includes` logic
happens *after* `stripLen` is applied, so we can't match on `subdir/*`.
This change adds a `relative` argument that makes this possible by
filtering files before doing any processing, and setting `stripLen` and
`extraPrefix` accordingly.
types.optionSet has been deprecated for almost 10 years now
(0e333688ce)! A removal
was already attempted in 2019
(27982b408e), but it was promptly
reinstantiated since some third-party uses were discovered
(f531ce75e4178c6867cc1d0f7fec96b2d5c3f1cb).
It's finally time to remove it for good :)
The documentation for this diagram explains that the blue arrows are
automatic processes which happen every six hours. There is no
explanation about how the purple arrows happen or how often.
As a new contributor to nixpkgs, I incorrectly assumed that the purple
arrows were also automatic processes (they aren't), which left me sort
of confused about what the whole scheme was accomplishing.
Recently I went through the github history to see how often these
events happen, and realized that the purple arrows are (a) triggered
manually by a nixpkgs project member and (b) happen much, much, much
less frequently than every six hours.
Now everything makes a lot more sense. I suggest the wording change
in this commit, or something similar, to save future contributors the
same confusion that I experienced.
The current doc is wildly out of touch with reality. A regex search shows
the following stats.
```
Style example Frequency Regex used
nix-2-5: 8 [a-zA-Z]-[0-9]+(-[0-9]+)+ =
nix-2_5: 17 [a-zA-Z]-[0-9]+(_[0-9]+)+ =
nix_2_5: 689 [a-zA-Z]_[0-9]+(_[0-9]+)+ =
nix_2-5: 1 [a-zA-Z]_[0-9]+(-[0-9]+)+ =
```
3s is too small a margin for a loaded slow system to start a bloated
program.
This leads to problems when tests are written on decent dev hardware
but later run on build farms of potentially slower hardware,
particularly in the case of non x86.
The chance of needing the timeout is actually very small, so those
rare 57s are a reasonable price to pay for fewer timeouts on build
farms, each of which should be investigated and usually fixed by
increasing the timeout.
We are still using Pandoc’s Markdown parser, which differs from CommonMark spec slightly.
Notably:
- Line breaks in lists behave differently.
- Admonitions do not support the simpler syntax https://github.com/jgm/commonmark-hs/issues/75
- The auto_identifiers uses a different algorithm – I made the previous ones explicit.
- Languages (classes) of code blocks cannot contain whitespace so we have to use “pycon” alias instead of Python “console” as GitHub’s linguist
While at it, I also fixed the following issues:
- ShellSesssion was used
- Removed some pointless docbook tags.
