doc: assign ids to many headings
without stable ids on headings we cannot generate stable links to these headings. nrd complains about this, but the current docbook workflow does not. a few generated ids remain, mostly in examples and footnotes. most of the examples are generated by nixdoc (which has since gained MD export functions, and the MD export does generate IDs).
This commit is contained in:
pennae
parent
4bb072f0a8
commit
052bb41410
|
|
@ -3,7 +3,7 @@
|
|||
Building software with Nix often requires downloading source code and other files from the internet.
|
||||
`nixpkgs` provides *fetchers* for different protocols and services. Fetchers are functions that simplify downloading files.
|
||||
|
||||
## Caveats
|
||||
## Caveats {#chap-pkgs-fetchers-caveats}
|
||||
|
||||
Fetchers create [fixed output derivations](https://nixos.org/manual/nix/stable/#fixed-output-drvs) from downloaded files.
|
||||
Nix can reuse the downloaded files via the hash of the resulting derivation.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Nix packages are most commonly shared between machines using [HTTP, SSH, or S3](
|
|||
|
||||
Note that this function is meant for advanced use-cases. The more idiomatic way to work with flat-file binary caches is via the [nix-copy-closure](https://nixos.org/manual/nix/stable/command-ref/nix-copy-closure.html) command. You may also want to consider [dockerTools](#sec-pkgs-dockerTools) for your containerization needs.
|
||||
|
||||
## Example
|
||||
## Example {#sec-pkgs-binary-cache-example}
|
||||
|
||||
The following derivation will construct a flat-file binary cache containing the closure of `hello`.
|
||||
|
||||
|
|
|
|||
|
|
@ -410,7 +410,7 @@ If the derivation is fully buildable (i.e. `nix-build` can be used on it), runni
|
|||
The behavior doesn't match `nix-shell` or `nix-build` exactly and this function is known not to work correctly for e.g. fixed-output derivations, content-addressed derivations, impure derivations and other special types of derivations.
|
||||
:::
|
||||
|
||||
### Arguments
|
||||
### Arguments {#ssec-pkgs-dockerTools-buildNixShellImage-arguments}
|
||||
|
||||
`drv`
|
||||
|
||||
|
|
@ -473,7 +473,7 @@ The behavior doesn't match `nix-shell` or `nix-build` exactly and this function
|
|||
|
||||
*Default:* (none)
|
||||
|
||||
### Example
|
||||
### Example {#ssec-pkgs-dockerTools-buildNixShellImage-example}
|
||||
|
||||
The following shows how to build the `pkgs.hello` package inside a Docker container built with `buildNixShellImage`.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,12 +12,12 @@ Whereas for many web servers, applications, it is possible to work with a Nix st
|
|||
|
||||
NixOS tests also use this function when preparing the VM. The `cptofs` method is used when `virtualisation.useBootLoader` is false (the default). Otherwise the second method is used.
|
||||
|
||||
## Features
|
||||
## Features {#sec-make-disk-image-features}
|
||||
|
||||
For reference, read the function signature source code for documentation on arguments: <https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/make-disk-image.nix>.
|
||||
Features are separated in various sections depending on if you opt for a Nix-store only image or a full NixOS image.
|
||||
|
||||
### Common
|
||||
### Common {#sec-make-disk-image-features-common}
|
||||
|
||||
- arbitrary NixOS configuration
|
||||
- automatic or bound disk size: `diskSize` parameter, `additionalSpace` can be set when `diskSize` is `auto` to add a constant of disk space
|
||||
|
|
@ -29,7 +29,7 @@ Features are separated in various sections depending on if you opt for a Nix-sto
|
|||
- the current nixpkgs can be realized as a channel in the disk image, which will change the hash of the image when the sources are updated
|
||||
- additional store paths can be provided through `additionalPaths`
|
||||
|
||||
### Full NixOS image
|
||||
### Full NixOS image {#sec-make-disk-image-features-full-image}
|
||||
|
||||
- arbitrary contents with permissions can be placed in the target filesystem using `contents`
|
||||
- a `/etc/nixpkgs/nixos/configuration.nix` can be provided through `configFile`
|
||||
|
|
@ -37,7 +37,7 @@ Features are separated in various sections depending on if you opt for a Nix-sto
|
|||
- EFI variables can be mutated during image production and the result is exposed in `$out`
|
||||
- boot partition size when partition table is `efi` or `hybrid`
|
||||
|
||||
### On bit-to-bit reproducibility
|
||||
### On bit-to-bit reproducibility {#sec-make-disk-image-features-reproducibility}
|
||||
|
||||
Images are **NOT** deterministic, please do not hesitate to try to fix this, source of determinisms are (not exhaustive) :
|
||||
|
||||
|
|
@ -47,7 +47,7 @@ Images are **NOT** deterministic, please do not hesitate to try to fix this, sou
|
|||
|
||||
A `deterministic` flag is available for best efforts determinism.
|
||||
|
||||
## Usage
|
||||
## Usage {#sec-make-disk-image-usage}
|
||||
|
||||
To produce a Nix-store only image:
|
||||
```nix
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ pkgs.makeSetupHook {
|
|||
} ./script.sh
|
||||
```
|
||||
|
||||
#### setup hook that depends on the hello package and runs hello and @shell@ is substituted with path to bash
|
||||
#### setup hook that depends on the hello package and runs hello and @shell@ is substituted with path to bash {#sec-pkgs.makeSetupHook-usage-example}
|
||||
|
||||
```nix
|
||||
pkgs.makeSetupHook {
|
||||
|
|
@ -27,7 +27,7 @@ pkgs.makeSetupHook {
|
|||
'')
|
||||
```
|
||||
|
||||
## Attributes
|
||||
## Attributes {#sec-pkgs.makeSetupHook-attributes}
|
||||
|
||||
* `name` Set the name of the hook.
|
||||
* `propagatedBuildInputs` Runtime dependencies (such as binaries) of the hook.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ pkgs.mkShell {
|
|||
}
|
||||
```
|
||||
|
||||
## Attributes
|
||||
## Attributes {#sec-pkgs-mkShell-attributes}
|
||||
|
||||
* `name` (default: `nix-shell`). Set the name of the derivation.
|
||||
* `packages` (default: `[]`). Add executable packages to the `nix-shell` environment.
|
||||
|
|
@ -29,7 +29,7 @@ pkgs.mkShell {
|
|||
|
||||
... all the attributes of `stdenv.mkDerivation`.
|
||||
|
||||
## Building the shell
|
||||
## Building the shell {#sec-pkgs-mkShell-building}
|
||||
|
||||
This derivation output will contain a text file that contains a reference to
|
||||
all the build inputs. This is useful in CI where we want to make sure that
|
||||
|
|
|
|||
|
|
@ -178,7 +178,7 @@ letting NixOS invoke Nixpkgs anew.
|
|||
If a test machine needs to set NixOS options under `nixpkgs`, it must set only the
|
||||
`nixpkgs.pkgs` option.
|
||||
|
||||
### Parameter
|
||||
### Parameter {#tester-nixosTest-parameter}
|
||||
|
||||
A [NixOS VM test network](https://nixos.org/nixos/manual/index.html#sec-nixos-tests), or path to it. Example:
|
||||
|
||||
|
|
@ -200,7 +200,7 @@ A [NixOS VM test network](https://nixos.org/nixos/manual/index.html#sec-nixos-te
|
|||
}
|
||||
```
|
||||
|
||||
### Result
|
||||
### Result {#tester-nixosTest-result}
|
||||
|
||||
A derivation that runs the VM test.
|
||||
|
||||
|
|
|
|||
|
|
@ -290,7 +290,7 @@ Other examples of reasons are:
|
|||
- The previous download links were all broken
|
||||
- Crash when starting on some X11 systems
|
||||
|
||||
#### Acceptable backport criteria
|
||||
#### Acceptable backport criteria {#acceptable-backport-criteria}
|
||||
|
||||
The stable branch does have some changes which cannot be backported. Most notable are breaking changes. The desire is to have stable users be uninterrupted when updating packages.
|
||||
|
||||
|
|
|
|||
|
|
@ -216,7 +216,7 @@ you can test whether it builds correctly by writing in a comment:
|
|||
@ofborg build agdaPackages.iowa-stdlib
|
||||
```
|
||||
|
||||
### Maintaining Agda packages
|
||||
### Maintaining Agda packages {#agda-maintaining-packages}
|
||||
|
||||
As mentioned before, the aim is to have a compatible, and up-to-date package set.
|
||||
These two conditions sometimes exclude each other:
|
||||
|
|
|
|||
|
|
@ -281,11 +281,11 @@ mkShell {
|
|||
}
|
||||
```
|
||||
|
||||
### Using an overlay
|
||||
### Using an overlay {#beam-using-overlays}
|
||||
|
||||
If you need to use an overlay to change some attributes of a derivation, e.g. if you need a bugfix from a version that is not yet available in nixpkgs, you can override attributes such as `version` (and the corresponding `hash`) and then use this overlay in your development environment:
|
||||
|
||||
#### `shell.nix`
|
||||
#### `shell.nix` {#beam-using-overlays-shell.nix}
|
||||
|
||||
```nix
|
||||
let
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
[R⁵RS](https://schemers.org/Documents/Standards/R5RS/HTML/)-compliant Scheme
|
||||
compiler. It includes an interactive mode and a custom package format, "eggs".
|
||||
|
||||
## Using Eggs
|
||||
## Using Eggs {#sec-chicken-using}
|
||||
|
||||
Eggs described in nixpkgs are available inside the
|
||||
`chickenPackages.chickenEggs` attrset. Including an egg as a build input is
|
||||
|
|
@ -22,7 +22,7 @@ might write:
|
|||
Both `chicken` and its eggs have a setup hook which configures the environment
|
||||
variables `CHICKEN_INCLUDE_PATH` and `CHICKEN_REPOSITORY_PATH`.
|
||||
|
||||
## Updating Eggs
|
||||
## Updating Eggs {#sec-chicken-updating-eggs}
|
||||
|
||||
nixpkgs only knows about a subset of all published eggs. It uses
|
||||
[egg2nix](https://github.com/the-kenny/egg2nix) to generate a
|
||||
|
|
@ -36,7 +36,7 @@ $ cd pkgs/development/compilers/chicken/5/
|
|||
$ egg2nix eggs.scm > eggs.nix
|
||||
```
|
||||
|
||||
## Adding Eggs
|
||||
## Adding Eggs {#sec-chicken-adding-eggs}
|
||||
|
||||
When we run `egg2nix`, we obtain one collection of eggs with
|
||||
mutually-compatible versions. This means that when we add new eggs, we may
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
- do configuration akin to [Dhall Lang](https://dhall-lang.org/)
|
||||
- perform data validation
|
||||
|
||||
## Cuelang schema quick start
|
||||
## Cuelang schema quick start {#cuelang-quickstart}
|
||||
|
||||
Cuelang schemas are similar to JSON, here is a quick cheatsheet:
|
||||
|
||||
|
|
@ -21,7 +21,7 @@ Cuelang schemas are similar to JSON, here is a quick cheatsheet:
|
|||
- Read <https://cuelang.org/docs/concepts/logic/> to learn more about the semantics.
|
||||
- Read <https://cuelang.org/docs/references/spec/> to learn about the language specification.
|
||||
|
||||
## `writeCueValidator`
|
||||
## `writeCueValidator` {#cuelang-writeCueValidator}
|
||||
|
||||
Nixpkgs provides a `pkgs.writeCueValidator` helper, which will write a validation script based on the provided Cuelang schema.
|
||||
|
||||
|
|
|
|||
|
|
@ -160,7 +160,7 @@ All `haskell.packages.*` package sets use the same package descriptions and the
|
|||
of versions by default. There are however GHC version specific override `.nix`
|
||||
files to loosen this a bit.
|
||||
|
||||
### Dependency resolution
|
||||
### Dependency resolution {#haskell-dependency-resolution}
|
||||
|
||||
Normally when you build Haskell packages with `cabal-install`, `cabal-install`
|
||||
does dependency resolution. It will look at all Haskell package versions known
|
||||
|
|
@ -230,7 +230,7 @@ specification, test suites, benchmarks etc. by compiling and invoking the
|
|||
package's `Setup.hs`. It does *not* use or invoke the `cabal-install` binary,
|
||||
but uses the underlying `Cabal` library instead.
|
||||
|
||||
### General arguments
|
||||
### General arguments {#haskell-derivation-args}
|
||||
|
||||
`pname`
|
||||
: Package name, assumed to be the same as on Hackage (if applicable)
|
||||
|
|
@ -479,7 +479,7 @@ are especially useful when writing [overrides](#haskell-overriding-haskell-packa
|
|||
when you want to make sure that they are definitely included. However, it is
|
||||
recommended to use the more accurate ones listed above when possible.
|
||||
|
||||
### Meta attributes
|
||||
### Meta attributes {#haskell-derivation-meta}
|
||||
|
||||
`haskellPackages.mkDerivation` accepts the following attributes as direct
|
||||
arguments which are transparently set in `meta` of the resulting derivation. See
|
||||
|
|
@ -714,7 +714,7 @@ editor plugin to achieve this.
|
|||
|
||||
## Overriding Haskell packages {#haskell-overriding-haskell-packages}
|
||||
|
||||
### Overriding a single package
|
||||
### Overriding a single package {#haskell-overriding-a-single-package}
|
||||
|
||||
<!-- TODO(@sternenseemann): we should document /somewhere/ that base == null etc. -->
|
||||
|
||||
|
|
@ -803,7 +803,7 @@ lib.pipe my-haskell-package [
|
|||
]
|
||||
```
|
||||
|
||||
#### `haskell.lib.compose`
|
||||
#### `haskell.lib.compose` {#haskell-haskell.lib.compose}
|
||||
|
||||
The base interface for all overriding is the following function:
|
||||
|
||||
|
|
@ -826,7 +826,7 @@ following overview. Refer to the
|
|||
[documentation of `haskellPackages.mkDerivation`](#haskell-mkderivation)
|
||||
for a more detailed description of the effects of the respective arguments.
|
||||
|
||||
##### Packaging Helpers
|
||||
##### Packaging Helpers {#haskell-packaging-helpers}
|
||||
|
||||
`overrideSrc { src, version } drv`
|
||||
: Replace the source used for building `drv` with the path or derivation given
|
||||
|
|
@ -875,7 +875,7 @@ sometimes necessary when working with versioned packages in
|
|||
altogether. Useful if it fails to evaluate cleanly and is causing
|
||||
noise in the evaluation errors tab on Hydra.
|
||||
|
||||
##### Development Helpers
|
||||
##### Development Helpers {#haskell-development-helpers}
|
||||
|
||||
`sdistTarball drv`
|
||||
: Create a source distribution tarball like those found on Hackage
|
||||
|
|
@ -913,7 +913,7 @@ for debugging with e.g. `gdb`.
|
|||
|
||||
<!-- TODO(@sternenseemann): shellAware -->
|
||||
|
||||
##### Trivial Helpers
|
||||
##### Trivial Helpers {#haskell-trivial-helpers}
|
||||
|
||||
`doJailbreak drv`
|
||||
: Sets the `jailbreak` argument to `true` for `drv`.
|
||||
|
|
@ -998,7 +998,7 @@ benchmark component.
|
|||
`dontCoverage drv`
|
||||
: Sets the `doCoverage` argument to `false` for `drv`.
|
||||
|
||||
#### Library functions in the Haskell package sets
|
||||
#### Library functions in the Haskell package sets {#haskell-package-set-lib-functions}
|
||||
|
||||
Some library functions depend on packages from the Haskell package sets. Thus they are
|
||||
exposed from those instead of from `haskell.lib.compose` which can only access what is
|
||||
|
|
@ -1062,7 +1062,7 @@ it does for the unstable branches.
|
|||
|
||||
## F.A.Q. {#haskell-faq}
|
||||
|
||||
### Why is topic X not covered in this section? Why is section Y missing?
|
||||
### Why is topic X not covered in this section? Why is section Y missing? {#haskell-why-not-covered}
|
||||
|
||||
We have been working on [moving the nixpkgs Haskell documentation back into the
|
||||
nixpkgs manual](https://github.com/NixOS/nixpkgs/issues/121403). Since this
|
||||
|
|
|
|||
|
|
@ -6,16 +6,16 @@ This contains instructions on how to package javascript applications.
|
|||
|
||||
The various tools available will be listed in the [tools-overview](#javascript-tools-overview). Some general principles for packaging will follow. Finally some tool specific instructions will be given.
|
||||
|
||||
## Getting unstuck / finding code examples
|
||||
## Getting unstuck / finding code examples {#javascript-finding-examples}
|
||||
|
||||
If you find you are lacking inspiration for packing javascript applications, the links below might prove useful. Searching online for prior art can be helpful if you are running into solved problems.
|
||||
|
||||
### Github
|
||||
### Github {#javascript-finding-examples-github}
|
||||
|
||||
- Searching Nix files for `mkYarnPackage`: <https://github.com/search?q=mkYarnPackage+language%3ANix&type=code>
|
||||
- Searching just `flake.nix` files for `mkYarnPackage`: <https://github.com/search?q=mkYarnPackage+filename%3Aflake.nix&type=code>
|
||||
|
||||
### Gitlab
|
||||
### Gitlab {#javascript-finding-examples-gitlab}
|
||||
|
||||
- Searching Nix files for `mkYarnPackage`: <https://gitlab.com/search?scope=blobs&search=mkYarnPackage+extension%3Anix>
|
||||
- Searching just `flake.nix` files for `mkYarnPackage`: <https://gitlab.com/search?scope=blobs&search=mkYarnPackage+filename%3Aflake.nix>
|
||||
|
|
@ -105,7 +105,7 @@ After you have identified the correct system, you need to override your package
|
|||
});
|
||||
```
|
||||
|
||||
### Adding and Updating Javascript packages in nixpkgs
|
||||
### Adding and Updating Javascript packages in nixpkgs {#javascript-adding-or-updating-packages}
|
||||
|
||||
To add a package from NPM to nixpkgs:
|
||||
|
||||
|
|
@ -140,7 +140,7 @@ To update NPM packages in nixpkgs, run the same `generate.sh` script:
|
|||
./pkgs/development/node-packages/generate.sh
|
||||
```
|
||||
|
||||
#### Git protocol error
|
||||
#### Git protocol error {#javascript-git-error}
|
||||
|
||||
Some packages may have Git dependencies from GitHub specified with `git://`.
|
||||
GitHub has [disabled unecrypted Git connections](https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git), so you may see the following error when running the generate script:
|
||||
|
|
@ -288,7 +288,7 @@ configurePhase = ''
|
|||
This will generate a derivation including the `node_modules` directory.
|
||||
If you have to build a derivation for an integrated web framework (rails, phoenix..), this is probably the easiest way.
|
||||
|
||||
#### Overriding dependency behavior
|
||||
#### Overriding dependency behavior {#javascript-mkYarnPackage-overriding-dependencies}
|
||||
|
||||
In the `mkYarnPackage` record the property `pkgConfig` can be used to override packages when you encounter problems building.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
Nixpkgs provides a couple of facilities for working with this tool.
|
||||
|
||||
## Writing packages providing pkg-config modules
|
||||
## Writing packages providing pkg-config modules {#pkg-config-writing-packages}
|
||||
|
||||
Packages should set `meta.pkgConfigModules` with the list of package config modules they provide.
|
||||
They should also use `testers.testMetaPkgConfig` to check that the final built package matches that list.
|
||||
|
|
@ -29,9 +29,9 @@ stdenv.mkDerivation (finalAttrs: {
|
|||
})
|
||||
```
|
||||
|
||||
## Accessing packages via pkg-config module name
|
||||
## Accessing packages via pkg-config module name {#sec-pkg-config-usage}
|
||||
|
||||
### Within Nixpkgs
|
||||
### Within Nixpkgs {#sec-pkg-config-usage-internal}
|
||||
|
||||
A [setup hook](#setup-hook-pkg-config) is bundled in the `pkg-config` package to bring a derivation's declared build inputs into the environment.
|
||||
This will populate environment variables like `PKG_CONFIG_PATH`, `PKG_CONFIG_PATH_FOR_BUILD`, and `PKG_CONFIG_PATH_HOST` based on:
|
||||
|
|
@ -44,7 +44,7 @@ For more details see the section on [specifying dependencies in general](#ssec-s
|
|||
|
||||
Normal pkg-config commands to look up dependencies by name will then work with those environment variables defined by the hook.
|
||||
|
||||
### Externally
|
||||
### Externally {#sec-pkg-config-usage-external}
|
||||
|
||||
The `defaultPkgConfigPackages` package set is a set of aliases, named after the modules they provide.
|
||||
This is meant to be used by language-to-nix integrations.
|
||||
|
|
|
|||
|
|
@ -1117,7 +1117,7 @@ with import <nixpkgs> {};
|
|||
in python.withPackages(ps: [ps.blaze])).env
|
||||
```
|
||||
|
||||
#### Optional extra dependencies
|
||||
#### Optional extra dependencies {#python-optional-dependencies}
|
||||
|
||||
Some packages define optional dependencies for additional features. With
|
||||
`setuptools` this is called `extras_require` and `flit` calls it
|
||||
|
|
@ -1801,14 +1801,14 @@ The following rules are desired to be respected:
|
|||
* Attribute names in `python-packages.nix` should be sorted alphanumerically to
|
||||
avoid merge conflicts and ease locating attributes.
|
||||
|
||||
## Package set maintenance
|
||||
## Package set maintenance {#python-package-set-maintenance}
|
||||
|
||||
The whole Python package set has a lot of packages that do not see regular
|
||||
updates, because they either are a very fragile component in the Python
|
||||
ecosystem, like for example the `hypothesis` package, or packages that have
|
||||
no maintainer, so maintenance falls back to the package set maintainers.
|
||||
|
||||
### Updating packages in bulk
|
||||
### Updating packages in bulk {#python-package-bulk-updates}
|
||||
|
||||
There is a tool to update alot of python libraries in bulk, it exists at
|
||||
`maintainers/scripts/update-python-libraries` with this repository.
|
||||
|
|
@ -1836,7 +1836,7 @@ would be:
|
|||
$ maintainers/scripts/update-python-libraries --target minor --commit --use-pkgs-prefix pkgs/development/python-modules/**/default.nix
|
||||
```
|
||||
|
||||
## CPython Update Schedule
|
||||
## CPython Update Schedule {#python-cpython-update-schedule}
|
||||
|
||||
With [PEP 602](https://www.python.org/dev/peps/pep-0602/), CPython now
|
||||
follows a yearly release cadence. In nixpkgs, all supported interpreters
|
||||
|
|
|
|||
|
|
@ -201,7 +201,7 @@ $ nix-shell --run 'ruby -rpg -e "puts PG.library_version"'
|
|||
|
||||
Of course for this use-case one could also use overlays since the configuration for `pg` depends on the `postgresql` alias, but for demonstration purposes this has to suffice.
|
||||
|
||||
### Platform-specific gems
|
||||
### Platform-specific gems {#ruby-platform-specif-gems}
|
||||
|
||||
Right now, bundix has some issues with pre-built, platform-specific gems: [bundix PR #68](https://github.com/nix-community/bundix/pull/68).
|
||||
Until this is solved, you can tell bundler to not use platform-specific gems and instead build them from source each time:
|
||||
|
|
|
|||
|
|
@ -166,8 +166,8 @@ in
|
|||
|
||||
If your package requires building specific parts, use instead `pkgs.vimUtils.buildVimPlugin`.
|
||||
|
||||
### Specificities for some plugins
|
||||
#### Treesitter
|
||||
### Specificities for some plugins {#vim-plugin-specificities}
|
||||
#### Treesitter {#vim-plugin-treesitter}
|
||||
|
||||
By default `nvim-treesitter` encourages you to download, compile and install
|
||||
the required Treesitter grammars at run time with `:TSInstall`. This works
|
||||
|
|
@ -244,7 +244,7 @@ Alternatively, set the number of processes to a lower count to avoid rate-limiti
|
|||
./pkgs/applications/editors/vim/plugins/update.py --proc 1
|
||||
```
|
||||
|
||||
## How to maintain an out-of-tree overlay of vim plugins ?
|
||||
## How to maintain an out-of-tree overlay of vim plugins ? {#vim-out-of-tree-overlays}
|
||||
|
||||
You can use the updater script to generate basic packages out of a custom vim
|
||||
plugin list:
|
||||
|
|
|
|||
|
|
@ -1,19 +1,20 @@
|
|||
<book xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude">
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="nixpkgs-manual">
|
||||
<info>
|
||||
<title>Nixpkgs Manual</title>
|
||||
<subtitle>Version <xi:include href=".version" parse="text" />
|
||||
</subtitle>
|
||||
</info>
|
||||
<xi:include href="preface.chapter.xml" />
|
||||
<part>
|
||||
<part xml:id="part-using">
|
||||
<title>Using Nixpkgs</title>
|
||||
<xi:include href="using/configuration.chapter.xml" />
|
||||
<xi:include href="using/overlays.chapter.xml" />
|
||||
<xi:include href="using/overrides.chapter.xml" />
|
||||
<xi:include href="functions.xml" />
|
||||
</part>
|
||||
<part>
|
||||
<part xml:id="part-stdenv">
|
||||
<title>Standard environment</title>
|
||||
<xi:include href="stdenv/stdenv.chapter.xml" />
|
||||
<xi:include href="stdenv/meta.chapter.xml" />
|
||||
|
|
@ -21,7 +22,7 @@
|
|||
<xi:include href="stdenv/cross-compilation.chapter.xml" />
|
||||
<xi:include href="stdenv/platform-notes.chapter.xml" />
|
||||
</part>
|
||||
<part>
|
||||
<part xml:id="part-builders">
|
||||
<title>Builders</title>
|
||||
<xi:include href="builders/fetchers.chapter.xml" />
|
||||
<xi:include href="builders/trivial-builders.chapter.xml" />
|
||||
|
|
@ -32,7 +33,7 @@
|
|||
<xi:include href="languages-frameworks/index.xml" />
|
||||
<xi:include href="builders/packages/index.xml" />
|
||||
</part>
|
||||
<part>
|
||||
<part xml:id="part-contributing">
|
||||
<title>Contributing to Nixpkgs</title>
|
||||
<xi:include href="contributing/quick-start.chapter.xml" />
|
||||
<xi:include href="contributing/coding-conventions.chapter.xml" />
|
||||
|
|
|
|||
|
|
@ -101,7 +101,7 @@ $ cd path/to/nixpkgs
|
|||
$ nix-build -A your-package.tests
|
||||
```
|
||||
|
||||
#### Package tests
|
||||
#### Package tests {#var-meta-tests-packages}
|
||||
|
||||
Tests that are part of the source package are often executed in the `installCheckPhase`.
|
||||
|
||||
|
|
@ -113,7 +113,7 @@ Prefer `passthru.tests` for tests that are introduced in nixpkgs because:
|
|||
|
||||
For more on how to write and run package tests, see <xref linkend="sec-package-tests"/>.
|
||||
|
||||
#### NixOS tests
|
||||
#### NixOS tests {#var-meta-tests-nixos}
|
||||
|
||||
The NixOS tests are available as `nixosTests` in parameters of derivations. For instance, the OpenSMTPD derivation includes lines similar to:
|
||||
|
||||
|
|
|
|||
|
|
@ -703,7 +703,7 @@ The prefix under which the package must be installed, passed via the `--prefix`
|
|||
|
||||
The key to use when specifying the prefix. By default, this is set to `--prefix=` as that is used by the majority of packages.
|
||||
|
||||
##### `dontAddStaticConfigureFlags`
|
||||
##### `dontAddStaticConfigureFlags` {#var-stdenv-dontAddStaticConfigureFlags}
|
||||
|
||||
By default, when building statically, stdenv will try to add build system appropriate configure flags to try to enable static builds.
|
||||
|
||||
|
|
@ -1095,15 +1095,15 @@ postInstall = ''
|
|||
|
||||
Performs string substitution on the contents of \<infile\>, writing the result to \<outfile\>. The substitutions in \<subs\> are of the following form:
|
||||
|
||||
#### `--replace` \<s1\> \<s2\>
|
||||
#### `--replace` \<s1\> \<s2\> {#fun-substitute-replace}
|
||||
|
||||
Replace every occurrence of the string \<s1\> by \<s2\>.
|
||||
|
||||
#### `--subst-var` \<varName\>
|
||||
#### `--subst-var` \<varName\> {#fun-substitute-subst-var}
|
||||
|
||||
Replace every occurrence of `@varName@` by the contents of the environment variable \<varName\>. This is useful for generating files from templates, using `@...@` in the template as placeholders.
|
||||
|
||||
#### `--subst-var-by` \<varName\> \<s\>
|
||||
#### `--subst-var-by` \<varName\> \<s\> {#fun-substitute-subst-var-by}
|
||||
|
||||
Replace every occurrence of `@varName@` by the string \<s\>.
|
||||
|
||||
|
|
@ -1244,7 +1244,7 @@ Multiple paths can be specified.
|
|||
patchShebangs [--build | --host] PATH...
|
||||
```
|
||||
|
||||
##### Flags
|
||||
##### Flags {#patch-shebangs.sh-invocation-flags}
|
||||
|
||||
`--build`
|
||||
: Look up commands available at build time
|
||||
|
|
@ -1252,7 +1252,7 @@ patchShebangs [--build | --host] PATH...
|
|||
`--host`
|
||||
: Look up commands available at run time
|
||||
|
||||
##### Examples
|
||||
##### Examples {#patch-shebangs.sh-invocation-examples}
|
||||
|
||||
```sh
|
||||
patchShebangs --host /nix/store/<hash>-hello-1.0/bin
|
||||
|
|
@ -1339,7 +1339,7 @@ Similarly, the CC Wrapper follows the Bintools Wrapper in defining standard envi
|
|||
|
||||
Here are some more packages that provide a setup hook. Since the list of hooks is extensible, this is not an exhaustive list. The mechanism is only to be used as a last resort, so it might cover most uses.
|
||||
|
||||
### Other hooks
|
||||
### Other hooks {#stdenv-other-hooks}
|
||||
|
||||
Many other packages provide hooks, that are not part of `stdenv`. You can find
|
||||
these in the [Hooks Reference](#chap-hooks).
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user