commit 052bb41410760535a5360cbb591cb54d538c2bcd · pyrox.dev/nixpkgs

+1 -1

doc/builders/fetchers.chapter.md

···

       3
       3
        
       Building software with Nix often requires downloading source code and other files from the internet.

     

       4
       4
        
       `nixpkgs` provides *fetchers* for different protocols and services. Fetchers are functions that simplify downloading files.

     

       5
       5
        
       

     

       6
       6
       -
       ## Caveats

     

       6
       6
       +
       ## Caveats {#chap-pkgs-fetchers-caveats}

     

       7
       7
        
       

     

       8
       8
        
       Fetchers create [fixed output derivations](https://nixos.org/manual/nix/stable/#fixed-output-drvs) from downloaded files.

     

       9
       9
        
       Nix can reuse the downloaded files via the hash of the resulting derivation.

+1 -1

doc/builders/images/binarycache.section.md

···

       6
       6
        
       

     

       7
       7
        
       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.

     

       8
       8
        
       

     

       9
       9
       -
       ## Example

     

       9
       9
       +
       ## Example {#sec-pkgs-binary-cache-example}

     

       10
       10
        
       

     

       11
       11
        
       The following derivation will construct a flat-file binary cache containing the closure of `hello`.

     

       12
       12

+2 -2

doc/builders/images/dockertools.section.md

···

       410
       410
        
       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.

     

       411
       411
        
       :::

     

       412
       412
        
       

     

       413
       413
       -
       ### Arguments

     

       413
       413
       +
       ### Arguments {#ssec-pkgs-dockerTools-buildNixShellImage-arguments}

     

       414
       414
        
       

     

       415
       415
        
       `drv`

     

       416
       416
        
       

     
···

       473
       473
        
       

     

       474
       474
        
           *Default:* (none)

     

       475
       475
        
       

     

       476
       476
       -
       ### Example

     

       476
       476
       +
       ### Example {#ssec-pkgs-dockerTools-buildNixShellImage-example}

     

       477
       477
        
       

     

       478
       478
        
       The following shows how to build the `pkgs.hello` package inside a Docker container built with `buildNixShellImage`.

     

       479
       479

+5 -5

doc/builders/images/makediskimage.section.md

···

       12
       12
        
       

     

       13
       13
        
       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.

     

       14
       14
        
       

     

       15
       15
       -
       ## Features

     

       15
       15
       +
       ## Features {#sec-make-disk-image-features}

     

       16
       16
        
       

     

       17
       17
        
       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>.

     

       18
       18
        
       Features are separated in various sections depending on if you opt for a Nix-store only image or a full NixOS image.

     

       19
       19
        
       

     

       20
       20
       -
       ### Common

     

       20
       20
       +
       ### Common {#sec-make-disk-image-features-common}

     

       21
       21
        
       

     

       22
       22
        
       - arbitrary NixOS configuration

     

       23
       23
        
       - automatic or bound disk size: `diskSize` parameter, `additionalSpace` can be set when `diskSize` is `auto` to add a constant of disk space

     
···

       29
       29
        
       - 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

     

       30
       30
        
       - additional store paths can be provided through `additionalPaths`

     

       31
       31
        
       

     

       32
       32
       -
       ### Full NixOS image

     

       32
       32
       +
       ### Full NixOS image {#sec-make-disk-image-features-full-image}

     

       33
       33
        
       

     

       34
       34
        
       - arbitrary contents with permissions can be placed in the target filesystem using `contents`

     

       35
       35
        
       - a `/etc/nixpkgs/nixos/configuration.nix` can be provided through `configFile`

     
···

       37
       37
        
       - EFI variables can be mutated during image production and the result is exposed in `$out`

     

       38
       38
        
       - boot partition size when partition table is `efi` or `hybrid`

     

       39
       39
        
       

     

       40
       40
       -
       ### On bit-to-bit reproducibility

     

       40
       40
       +
       ### On bit-to-bit reproducibility {#sec-make-disk-image-features-reproducibility}

     

       41
       41
        
       

     

       42
       42
        
       Images are **NOT** deterministic, please do not hesitate to try to fix this, source of determinisms are (not exhaustive) :

     

       43
       43
        
       

     
···

       47
       47
        
       

     

       48
       48
        
       A `deterministic` flag is available for best efforts determinism.

     

       49
       49
        
       

     

       50
       50
       -
       ## Usage

     

       50
       50
       +
       ## Usage {#sec-make-disk-image-usage}

     

       51
       51
        
       

     

       52
       52
        
       To produce a Nix-store only image:

     

       53
       53
        
       ```nix

+2 -2

doc/builders/special/makesetuphook.section.md

···

       12
       12
        
       } ./script.sh

     

       13
       13
        
       ```

     

       14
       14
        
       

     

       15
       15
       -
       #### setup hook that depends on the hello package and runs hello and @shell@ is substituted with path to bash

     

       15
       15
       +
       #### setup hook that depends on the hello package and runs hello and @shell@ is substituted with path to bash {#sec-pkgs.makeSetupHook-usage-example}

     

       16
       16
        
       

     

       17
       17
        
       ```nix

     

       18
       18
        
       pkgs.makeSetupHook {

     
···

       27
       27
        
       '')

     

       28
       28
        
       ```

     

       29
       29
        
       

     

       30
       30
       -
       ## Attributes

     

       30
       30
       +
       ## Attributes {#sec-pkgs.makeSetupHook-attributes}

     

       31
       31
        
       

     

       32
       32
        
       * `name` Set the name of the hook.

     

       33
       33
        
       * `propagatedBuildInputs` Runtime dependencies (such as binaries) of the hook.

+2 -2

doc/builders/special/mkshell.section.md

···

       20
       20
        
       }

     

       21
       21
        
       ```

     

       22
       22
        
       

     

       23
       23
       -
       ## Attributes

     

       23
       23
       +
       ## Attributes {#sec-pkgs-mkShell-attributes}

     

       24
       24
        
       

     

       25
       25
        
       * `name` (default: `nix-shell`). Set the name of the derivation.

     

       26
       26
        
       * `packages` (default: `[]`). Add executable packages to the `nix-shell` environment.

     
···

       29
       29
        
       

     

       30
       30
        
       ... all the attributes of `stdenv.mkDerivation`.

     

       31
       31
        
       

     

       32
       32
       -
       ## Building the shell

     

       32
       32
       +
       ## Building the shell {#sec-pkgs-mkShell-building}

     

       33
       33
        
       

     

       34
       34
        
       This derivation output will contain a text file that contains a reference to

     

       35
       35
        
       all the build inputs. This is useful in CI where we want to make sure that

+2 -2

doc/builders/testers.chapter.md

···

       178
       178
        
       If a test machine needs to set NixOS options under `nixpkgs`, it must set only the

     

       179
       179
        
       `nixpkgs.pkgs` option.

     

       180
       180
        
       

     

       181
       181
       -
       ### Parameter

     

       181
       181
       +
       ### Parameter {#tester-nixosTest-parameter}

     

       182
       182
        
       

     

       183
       183
        
       A [NixOS VM test network](https://nixos.org/nixos/manual/index.html#sec-nixos-tests), or path to it. Example:

     

       184
       184
        
       

     
···

       200
       200
        
       }

     

       201
       201
        
       ```

     

       202
       202
        
       

     

       203
       203
       -
       ### Result

     

       203
       203
       +
       ### Result {#tester-nixosTest-result}

     

       204
       204
        
       

     

       205
       205
        
       A derivation that runs the VM test.

     

       206
       206

+1 -1

doc/contributing/submitting-changes.chapter.md

···

       290
       290
        
       - The previous download links were all broken

     

       291
       291
        
       - Crash when starting on some X11 systems

     

       292
       292
        
       

     

       293
       293
       -
       #### Acceptable backport criteria

     

       293
       293
       +
       #### Acceptable backport criteria {#acceptable-backport-criteria}

     

       294
       294
        
       

     

       295
       295
        
       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.

     

       296
       296

+1 -1

doc/languages-frameworks/agda.section.md

···

       216
       216
        
       @ofborg build agdaPackages.iowa-stdlib

     

       217
       217
        
       ```

     

       218
       218
        
       

     

       219
       219
       -
       ### Maintaining Agda packages

     

       219
       219
       +
       ### Maintaining Agda packages {#agda-maintaining-packages}

     

       220
       220
        
       

     

       221
       221
        
       As mentioned before, the aim is to have a compatible, and up-to-date package set.

     

       222
       222
        
       These two conditions sometimes exclude each other:

+2 -2

doc/languages-frameworks/beam.section.md

···

       281
       281
        
       }

     

       282
       282
        
       ```

     

       283
       283
        
       

     

       284
       284
       -
       ### Using an overlay

     

       284
       284
       +
       ### Using an overlay {#beam-using-overlays}

     

       285
       285
        
       

     

       286
       286
        
       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:

     

       287
       287
        
       

     

       288
       288
       -
       #### `shell.nix`

     

       288
       288
       +
       #### `shell.nix` {#beam-using-overlays-shell.nix}

     

       289
       289
        
       

     

       290
       290
        
       ```nix

     

       291
       291
        
       let

+3 -3

doc/languages-frameworks/chicken.section.md

···

       4
       4
        
       [R⁵RS](https://schemers.org/Documents/Standards/R5RS/HTML/)-compliant Scheme

     

       5
       5
        
       compiler. It includes an interactive mode and a custom package format, "eggs".

     

       6
       6
        
       

     

       7
       7
       -
       ## Using Eggs

     

       7
       7
       +
       ## Using Eggs {#sec-chicken-using}

     

       8
       8
        
       

     

       9
       9
        
       Eggs described in nixpkgs are available inside the

     

       10
       10
        
       `chickenPackages.chickenEggs` attrset. Including an egg as a build input is

     
···

       22
       22
        
       Both `chicken` and its eggs have a setup hook which configures the environment

     

       23
       23
        
       variables `CHICKEN_INCLUDE_PATH` and `CHICKEN_REPOSITORY_PATH`.

     

       24
       24
        
       

     

       25
       25
       -
       ## Updating Eggs

     

       25
       25
       +
       ## Updating Eggs {#sec-chicken-updating-eggs}

     

       26
       26
        
       

     

       27
       27
        
       nixpkgs only knows about a subset of all published eggs. It uses

     

       28
       28
        
       [egg2nix](https://github.com/the-kenny/egg2nix) to generate a

     
···

       36
       36
        
       $ egg2nix eggs.scm > eggs.nix

     

       37
       37
        
       ```

     

       38
       38
        
       

     

       39
       39
       -
       ## Adding Eggs

     

       39
       39
       +
       ## Adding Eggs {#sec-chicken-adding-eggs}

     

       40
       40
        
       

     

       41
       41
        
       When we run `egg2nix`, we obtain one collection of eggs with

     

       42
       42
        
       mutually-compatible versions. This means that when we add new eggs, we may

+2 -2

doc/languages-frameworks/cuelang.section.md

···

       7
       7
        
       - do configuration akin to [Dhall Lang](https://dhall-lang.org/)

     

       8
       8
        
       - perform data validation

     

       9
       9
        
       

     

       10
       10
       -
       ## Cuelang schema quick start

     

       10
       10
       +
       ## Cuelang schema quick start {#cuelang-quickstart}

     

       11
       11
        
       

     

       12
       12
        
       Cuelang schemas are similar to JSON, here is a quick cheatsheet:

     

       13
       13
        
       

     
···

       21
       21
        
       - Read <https://cuelang.org/docs/concepts/logic/> to learn more about the semantics.

     

       22
       22
        
       - Read <https://cuelang.org/docs/references/spec/> to learn about the language specification.

     

       23
       23
        
       

     

       24
       24
       -
       ## `writeCueValidator`

     

       24
       24
       +
       ## `writeCueValidator` {#cuelang-writeCueValidator}

     

       25
       25
        
       

     

       26
       26
        
       Nixpkgs provides a `pkgs.writeCueValidator` helper, which will write a validation script based on the provided Cuelang schema.

     

       27
       27

+10 -10

doc/languages-frameworks/haskell.section.md

···

       160
       160
        
       of versions by default. There are however GHC version specific override `.nix`

     

       161
       161
        
       files to loosen this a bit.

     

       162
       162
        
       

     

       163
       163
       -
       ### Dependency resolution

     

       163
       163
       +
       ### Dependency resolution {#haskell-dependency-resolution}

     

       164
       164
        
       

     

       165
       165
        
       Normally when you build Haskell packages with `cabal-install`, `cabal-install`

     

       166
       166
        
       does dependency resolution. It will look at all Haskell package versions known

     
···

       230
       230
        
       package's `Setup.hs`. It does *not* use or invoke the `cabal-install` binary,

     

       231
       231
        
       but uses the underlying `Cabal` library instead.

     

       232
       232
        
       

     

       233
       233
       -
       ### General arguments

     

       233
       233
       +
       ### General arguments {#haskell-derivation-args}

     

       234
       234
        
       

     

       235
       235
        
       `pname`

     

       236
       236
        
       : Package name, assumed to be the same as on Hackage (if applicable)

     
···

       479
       479
        
       when you want to make sure that they are definitely included. However, it is

     

       480
       480
        
       recommended to use the more accurate ones listed above when possible.

     

       481
       481
        
       

     

       482
       482
       -
       ### Meta attributes

     

       482
       482
       +
       ### Meta attributes {#haskell-derivation-meta}

     

       483
       483
        
       

     

       484
       484
        
       `haskellPackages.mkDerivation` accepts the following attributes as direct

     

       485
       485
        
       arguments which are transparently set in `meta` of the resulting derivation. See

     
···

       714
       714
        
       

     

       715
       715
        
       ## Overriding Haskell packages {#haskell-overriding-haskell-packages}

     

       716
       716
        
       

     

       717
       717
       -
       ### Overriding a single package

     

       717
       717
       +
       ### Overriding a single package {#haskell-overriding-a-single-package}

     

       718
       718
        
       

     

       719
       719
        
       <!-- TODO(@sternenseemann): we should document /somewhere/ that base == null etc. -->

     

       720
       720
        
       

     
···

       803
       803
        
       ]

     

       804
       804
        
       ```

     

       805
       805
        
       

     

       806
       806
       -
       #### `haskell.lib.compose`

     

       806
       806
       +
       #### `haskell.lib.compose` {#haskell-haskell.lib.compose}

     

       807
       807
        
       

     

       808
       808
        
       The base interface for all overriding is the following function:

     

       809
       809
        
       

     
···

       826
       826
        
       [documentation of `haskellPackages.mkDerivation`](#haskell-mkderivation)

     

       827
       827
        
       for a more detailed description of the effects of the respective arguments.

     

       828
       828
        
       

     

       829
       829
       -
       ##### Packaging Helpers

     

       829
       829
       +
       ##### Packaging Helpers {#haskell-packaging-helpers}

     

       830
       830
        
       

     

       831
       831
        
       `overrideSrc { src, version } drv`

     

       832
       832
        
       : Replace the source used for building `drv` with the path or derivation given

     
···

       875
       875
        
       altogether. Useful if it fails to evaluate cleanly and is causing

     

       876
       876
        
       noise in the evaluation errors tab on Hydra.

     

       877
       877
        
       

     

       878
       878
       -
       ##### Development Helpers

     

       878
       878
       +
       ##### Development Helpers {#haskell-development-helpers}

     

       879
       879
        
       

     

       880
       880
        
       `sdistTarball drv`

     

       881
       881
        
       : Create a source distribution tarball like those found on Hackage

     
···

       913
       913
        
       

     

       914
       914
        
       <!-- TODO(@sternenseemann): shellAware -->

     

       915
       915
        
       

     

       916
       916
       -
       ##### Trivial Helpers

     

       916
       916
       +
       ##### Trivial Helpers {#haskell-trivial-helpers}

     

       917
       917
        
       

     

       918
       918
        
       `doJailbreak drv`

     

       919
       919
        
       : Sets the `jailbreak` argument to `true` for `drv`.

     
···

       998
       998
        
       `dontCoverage drv`

     

       999
       999
        
       : Sets the `doCoverage` argument to `false` for `drv`.

     

       1000
       1000
        
       

     

       1001
       1001
       -
       #### Library functions in the Haskell package sets

     

       1001
       1001
       +
       #### Library functions in the Haskell package sets {#haskell-package-set-lib-functions}

     

       1002
       1002
        
       

     

       1003
       1003
        
       Some library functions depend on packages from the Haskell package sets. Thus they are

     

       1004
       1004
        
       exposed from those instead of from `haskell.lib.compose` which can only access what is

     
···

       1062
       1062
        
       

     

       1063
       1063
        
       ## F.A.Q. {#haskell-faq}

     

       1064
       1064
        
       

     

       1065
       1065
       -
       ### Why is topic X not covered in this section? Why is section Y missing?

     

       1065
       1065
       +
       ### Why is topic X not covered in this section? Why is section Y missing? {#haskell-why-not-covered}

     

       1066
       1066
        
       

     

       1067
       1067
        
       We have been working on [moving the nixpkgs Haskell documentation back into the

     

       1068
       1068
        
       nixpkgs manual](https://github.com/NixOS/nixpkgs/issues/121403). Since this

+6 -6

doc/languages-frameworks/javascript.section.md

···

       6
       6
        
       

     

       7
       7
        
       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.

     

       8
       8
        
       

     

       9
       9
       -
       ## Getting unstuck / finding code examples

     

       9
       9
       +
       ## Getting unstuck / finding code examples {#javascript-finding-examples}

     

       10
       10
        
       

     

       11
       11
        
       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.

     

       12
       12
        
       

     

       13
       13
       -
       ### Github

     

       13
       13
       +
       ### Github {#javascript-finding-examples-github}

     

       14
       14
        
       

     

       15
       15
        
       - Searching Nix files for `mkYarnPackage`: <https://github.com/search?q=mkYarnPackage+language%3ANix&type=code>

     

       16
       16
        
       - Searching just `flake.nix` files for `mkYarnPackage`: <https://github.com/search?q=mkYarnPackage+filename%3Aflake.nix&type=code>

     

       17
       17
        
       

     

       18
       18
       -
       ### Gitlab

     

       18
       18
       +
       ### Gitlab {#javascript-finding-examples-gitlab}

     

       19
       19
        
       

     

       20
       20
        
       - Searching Nix files for `mkYarnPackage`: <https://gitlab.com/search?scope=blobs&search=mkYarnPackage+extension%3Anix>

     

       21
       21
        
       - Searching just `flake.nix` files for `mkYarnPackage`: <https://gitlab.com/search?scope=blobs&search=mkYarnPackage+filename%3Aflake.nix>

     
···

       105
       105
        
           });

     

       106
       106
        
       ```

     

       107
       107
        
       

     

       108
       108
       -
       ### Adding and Updating Javascript packages in nixpkgs

     

       108
       108
       +
       ### Adding and Updating Javascript packages in nixpkgs {#javascript-adding-or-updating-packages}

     

       109
       109
        
       

     

       110
       110
        
       To add a package from NPM to nixpkgs:

     

       111
       111
        
       

     
···

       140
       140
        
       ./pkgs/development/node-packages/generate.sh

     

       141
       141
        
       ```

     

       142
       142
        
       

     

       143
       143
       -
       #### Git protocol error

     

       143
       143
       +
       #### Git protocol error {#javascript-git-error}

     

       144
       144
        
       

     

       145
       145
        
       Some packages may have Git dependencies from GitHub specified with `git://`.

     

       146
       146
        
       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
       288
        
       This will generate a derivation including the `node_modules` directory.

     

       289
       289
        
       If you have to build a derivation for an integrated web framework (rails, phoenix..), this is probably the easiest way.

     

       290
       290
        
       

     

       291
       291
       -
       #### Overriding dependency behavior

     

       291
       291
       +
       #### Overriding dependency behavior {#javascript-mkYarnPackage-overriding-dependencies}

     

       292
       292
        
       

     

       293
       293
        
       In the `mkYarnPackage` record the property `pkgConfig` can be used to override packages when you encounter problems building.

     

       294
       294

+4 -4

doc/languages-frameworks/pkg-config.section.md

···

       4
       4
        
       

     

       5
       5
        
       Nixpkgs provides a couple of facilities for working with this tool.

     

       6
       6
        
       

     

       7
       7
       -
       ## Writing packages providing pkg-config modules

     

       7
       7
       +
       ## Writing packages providing pkg-config modules {#pkg-config-writing-packages}

     

       8
       8
        
       

     

       9
       9
        
       Packages should set `meta.pkgConfigModules` with the list of package config modules they provide.

     

       10
       10
        
       They should also use `testers.testMetaPkgConfig` to check that the final built package matches that list.

     
···

       29
       29
        
       })

     

       30
       30
        
       ```

     

       31
       31
        
       

     

       32
       32
       -
       ## Accessing packages via pkg-config module name

     

       32
       32
       +
       ## Accessing packages via pkg-config module name {#sec-pkg-config-usage}

     

       33
       33
        
       

     

       34
       34
       -
       ### Within Nixpkgs

     

       34
       34
       +
       ### Within Nixpkgs {#sec-pkg-config-usage-internal}

     

       35
       35
        
       

     

       36
       36
        
       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.

     

       37
       37
        
       This will populate environment variables like `PKG_CONFIG_PATH`, `PKG_CONFIG_PATH_FOR_BUILD`, and `PKG_CONFIG_PATH_HOST` based on:

     
···

       44
       44
        
       

     

       45
       45
        
       Normal pkg-config commands to look up dependencies by name will then work with those environment variables defined by the hook.

     

       46
       46
        
       

     

       47
       47
       -
       ### Externally

     

       47
       47
       +
       ### Externally {#sec-pkg-config-usage-external}

     

       48
       48
        
       

     

       49
       49
        
       The `defaultPkgConfigPackages` package set is a set of aliases, named after the modules they provide.

     

       50
       50
        
       This is meant to be used by language-to-nix integrations.

+4 -4

doc/languages-frameworks/python.section.md

···

       1117
       1117
        
       in python.withPackages(ps: [ps.blaze])).env

     

       1118
       1118
        
       ```

     

       1119
       1119
        
       

     

       1120
       1120
       -
       #### Optional extra dependencies

     

       1120
       1120
       +
       #### Optional extra dependencies {#python-optional-dependencies}

     

       1121
       1121
        
       

     

       1122
       1122
        
       Some packages define optional dependencies for additional features. With

     

       1123
       1123
        
       `setuptools` this is called `extras_require` and `flit` calls it

     
···

       1801
       1801
        
       * Attribute names in `python-packages.nix` should be sorted alphanumerically to

     

       1802
       1802
        
         avoid merge conflicts and ease locating attributes.

     

       1803
       1803
        
       

     

       1804
       1804
       -
       ## Package set maintenance

     

       1804
       1804
       +
       ## Package set maintenance {#python-package-set-maintenance}

     

       1805
       1805
        
       

     

       1806
       1806
        
       The whole Python package set has a lot of packages that do not see regular

     

       1807
       1807
        
       updates, because they either are a very fragile component in the Python

     

       1808
       1808
        
       ecosystem, like for example the `hypothesis` package, or packages that have

     

       1809
       1809
        
       no maintainer, so maintenance falls back to the package set maintainers.

     

       1810
       1810
        
       

     

       1811
       1811
       -
       ### Updating packages in bulk

     

       1811
       1811
       +
       ### Updating packages in bulk {#python-package-bulk-updates}

     

       1812
       1812
        
       

     

       1813
       1813
        
       There is a tool to update alot of python libraries in bulk, it exists at

     

       1814
       1814
        
       `maintainers/scripts/update-python-libraries` with this repository.

     
···

       1836
       1836
        
       $ maintainers/scripts/update-python-libraries --target minor --commit --use-pkgs-prefix pkgs/development/python-modules/**/default.nix

     

       1837
       1837
        
       ```

     

       1838
       1838
        
       

     

       1839
       1839
       -
       ## CPython Update Schedule

     

       1839
       1839
       +
       ## CPython Update Schedule {#python-cpython-update-schedule}

     

       1840
       1840
        
       

     

       1841
       1841
        
       With [PEP 602](https://www.python.org/dev/peps/pep-0602/), CPython now

     

       1842
       1842
        
       follows a yearly release cadence. In nixpkgs, all supported interpreters

+1 -1

doc/languages-frameworks/ruby.section.md

···

       201
       201
        
       

     

       202
       202
        
       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.

     

       203
       203
        
       

     

       204
       204
       -
       ### Platform-specific gems

     

       204
       204
       +
       ### Platform-specific gems {#ruby-platform-specif-gems}

     

       205
       205
        
       

     

       206
       206
        
       Right now, bundix has some issues with pre-built, platform-specific gems: [bundix PR #68](https://github.com/nix-community/bundix/pull/68).

     

       207
       207
        
       Until this is solved, you can tell bundler to not use platform-specific gems and instead build them from source each time:

+3 -3

doc/languages-frameworks/vim.section.md

···

       166
       166
        
       

     

       167
       167
        
       If your package requires building specific parts, use instead `pkgs.vimUtils.buildVimPlugin`.

     

       168
       168
        
       

     

       169
       169
       -
       ### Specificities for some plugins

     

       170
       170
       -
       #### Treesitter

     

       169
       169
       +
       ### Specificities for some plugins {#vim-plugin-specificities}

     

       170
       170
       +
       #### Treesitter {#vim-plugin-treesitter}

     

       171
       171
        
       

     

       172
       172
        
       By default `nvim-treesitter` encourages you to download, compile and install

     

       173
       173
        
       the required Treesitter grammars at run time with `:TSInstall`. This works

     
···

       244
       244
        
       ./pkgs/applications/editors/vim/plugins/update.py --proc 1

     

       245
       245
        
       ```

     

       246
       246
        
       

     

       247
       247
       -
       ## How to maintain an out-of-tree overlay of vim plugins ?

     

       247
       247
       +
       ## How to maintain an out-of-tree overlay of vim plugins ? {#vim-out-of-tree-overlays}

     

       248
       248
        
       

     

       249
       249
        
       You can use the updater script to generate basic packages out of a custom vim

     

       250
       250
        
       plugin list:

+6 -5

doc/manual.xml

···

       1
       1
        
       <book xmlns="http://docbook.org/ns/docbook"

     

       2
       2
       -
             xmlns:xi="http://www.w3.org/2001/XInclude">

     

       2
       2
       +
             xmlns:xi="http://www.w3.org/2001/XInclude"

     

       3
       3
       +
             xml:id="nixpkgs-manual">

     

       3
       4
        
        <info>

     

       4
       5
        
         <title>Nixpkgs Manual</title>

     

       5
       6
        
         <subtitle>Version <xi:include href=".version" parse="text" />

     

       6
       7
        
         </subtitle>

     

       7
       8
        
        </info>

     

       8
       9
        
        <xi:include href="preface.chapter.xml" />

     

       9
       9
       -
        <part>

     

       10
       10
       +
        <part xml:id="part-using">

     

       10
       11
        
         <title>Using Nixpkgs</title>

     

       11
       12
        
         <xi:include href="using/configuration.chapter.xml" />

     

       12
       13
        
         <xi:include href="using/overlays.chapter.xml" />

     

       13
       14
        
         <xi:include href="using/overrides.chapter.xml" />

     

       14
       15
        
         <xi:include href="functions.xml" />

     

       15
       16
        
        </part>

     

       16
       16
       -
        <part>

     

       17
       17
       +
        <part xml:id="part-stdenv">

     

       17
       18
        
         <title>Standard environment</title>

     

       18
       19
        
         <xi:include href="stdenv/stdenv.chapter.xml" />

     

       19
       20
        
         <xi:include href="stdenv/meta.chapter.xml" />

     
···

       21
       22
        
         <xi:include href="stdenv/cross-compilation.chapter.xml" />

     

       22
       23
        
         <xi:include href="stdenv/platform-notes.chapter.xml" />

     

       23
       24
        
        </part>

     

       24
       24
       -
        <part>

     

       25
       25
       +
        <part xml:id="part-builders">

     

       25
       26
        
         <title>Builders</title>

     

       26
       27
        
         <xi:include href="builders/fetchers.chapter.xml" />

     

       27
       28
        
         <xi:include href="builders/trivial-builders.chapter.xml" />

     
···

       32
       33
        
         <xi:include href="languages-frameworks/index.xml" />

     

       33
       34
        
         <xi:include href="builders/packages/index.xml" />

     

       34
       35
        
        </part>

     

       35
       35
       -
        <part>

     

       36
       36
       +
        <part xml:id="part-contributing">

     

       36
       37
        
         <title>Contributing to Nixpkgs</title>

     

       37
       38
        
         <xi:include href="contributing/quick-start.chapter.xml" />

     

       38
       39
        
         <xi:include href="contributing/coding-conventions.chapter.xml" />

+2 -2

doc/stdenv/meta.chapter.md

···

       101
       101
        
       $ nix-build -A your-package.tests

     

       102
       102
        
       ```

     

       103
       103
        
       

     

       104
       104
       -
       #### Package tests

     

       104
       104
       +
       #### Package tests {#var-meta-tests-packages}

     

       105
       105
        
       

     

       106
       106
        
       Tests that are part of the source package are often executed in the `installCheckPhase`.

     

       107
       107
        
       

     
···

       113
       113
        
       

     

       114
       114
        
       For more on how to write and run package tests, see <xref linkend="sec-package-tests"/>.

     

       115
       115
        
       

     

       116
       116
       -
       #### NixOS tests

     

       116
       116
       +
       #### NixOS tests {#var-meta-tests-nixos}

     

       117
       117
        
       

     

       118
       118
        
       The NixOS tests are available as `nixosTests` in parameters of derivations. For instance, the OpenSMTPD derivation includes lines similar to:

     

       119
       119

+7 -7

doc/stdenv/stdenv.chapter.md

···

       703
       703
        
       

     

       704
       704
        
       The key to use when specifying the prefix. By default, this is set to `--prefix=` as that is used by the majority of packages.

     

       705
       705
        
       

     

       706
       706
       -
       ##### `dontAddStaticConfigureFlags`

     

       706
       706
       +
       ##### `dontAddStaticConfigureFlags` {#var-stdenv-dontAddStaticConfigureFlags}

     

       707
       707
        
       

     

       708
       708
        
       By default, when building statically, stdenv will try to add build system appropriate configure flags to try to enable static builds.

     

       709
       709
        
       

     
···

       1095
       1095
        
       

     

       1096
       1096
        
       Performs string substitution on the contents of \<infile\>, writing the result to \<outfile\>. The substitutions in \<subs\> are of the following form:

     

       1097
       1097
        
       

     

       1098
       1098
       -
       #### `--replace` \<s1\> \<s2\>

     

       1098
       1098
       +
       #### `--replace` \<s1\> \<s2\> {#fun-substitute-replace}

     

       1099
       1099
        
       

     

       1100
       1100
        
       Replace every occurrence of the string \<s1\> by \<s2\>.

     

       1101
       1101
        
       

     

       1102
       1102
       -
       #### `--subst-var` \<varName\>

     

       1102
       1102
       +
       #### `--subst-var` \<varName\> {#fun-substitute-subst-var}

     

       1103
       1103
        
       

     

       1104
       1104
        
       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.

     

       1105
       1105
        
       

     

       1106
       1106
       -
       #### `--subst-var-by` \<varName\> \<s\>

     

       1106
       1106
       +
       #### `--subst-var-by` \<varName\> \<s\> {#fun-substitute-subst-var-by}

     

       1107
       1107
        
       

     

       1108
       1108
        
       Replace every occurrence of `@varName@` by the string \<s\>.

     

       1109
       1109
        
       

     
···

       1244
       1244
        
       patchShebangs [--build | --host] PATH...

     

       1245
       1245
        
       ```

     

       1246
       1246
        
       

     

       1247
       1247
       -
       ##### Flags

     

       1247
       1247
       +
       ##### Flags {#patch-shebangs.sh-invocation-flags}

     

       1248
       1248
        
       

     

       1249
       1249
        
       `--build`

     

       1250
       1250
        
       : Look up commands available at build time

     
···

       1252
       1252
        
       `--host`

     

       1253
       1253
        
       : Look up commands available at run time

     

       1254
       1254
        
       

     

       1255
       1255
       -
       ##### Examples

     

       1255
       1255
       +
       ##### Examples {#patch-shebangs.sh-invocation-examples}

     

       1256
       1256
        
       

     

       1257
       1257
        
       ```sh

     

       1258
       1258
        
       patchShebangs --host /nix/store/<hash>-hello-1.0/bin

     
···

       1339
       1339
        
       

     

       1340
       1340
        
       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.

     

       1341
       1341
        
       

     

       1342
       1342
       -
       ### Other hooks

     

       1342
       1342
       +
       ### Other hooks {#stdenv-other-hooks}

     

       1343
       1343
        
       

     

       1344
       1344
        
       Many other packages provide hooks, that are not part of `stdenv`. You can find

     

       1345
       1345
        
       these in the [Hooks Reference](#chap-hooks).