summary refs log tree commit diff
path: root/doc/functions.xml
Commit message (Collapse)AuthorAge
* doc/functions/generators: convert to CommonMarkRyan Mulligan2021-06-11
|
* doc/functions/prefer-remote-fetch: convert to CommonMarkRyan Mulligan2021-06-07
|
* doc/functions/debug: convert to CommonMarkRyan Mulligan2021-06-07
|
* doc: nix-gitignore to CommonMarkAntoine Martin2021-06-05
| | | | Closes #125670
* doc: move fhs and mkShell under builders/specialFrederik Rietdijk2019-10-21
| | | | | | In my opinion Functions should only contain pure functions. These are both meant to provide derivations so I put them under Builders. Don't know exactly *where* to put them so "special" it is...
* doc: move overrides into separate chapterFrederik Rietdijk2019-10-21
|
* doc: move image builders into new images chapterFrederik Rietdijk2019-10-21
|
* doc: move fetchers and trivial builders under buildersFrederik Rietdijk2019-10-20
|
* doc: re-formatJan Tojnar2019-09-18
|
* ociTools: initKatharina Fey2019-09-04
|
* snapTools.makeSnap: initGraham Christensen2019-06-18
|
* Merge pull request #54693 from tilpner/appimage-toolsGraham Christensen2019-02-23
|\ | | | | appimageTools: init
| * appimageTools: inittilpner2019-02-23
| | | | | | | | | | | | | | | | | | | | | | | | The appimageTools attrset contains utilities to prevent the usage of appimage-run to package AppImages, like done/attempted in #49370 and #53156. This has the advantage of allowing for per-package environment changes, and extracts into the store instead of the users home directory. The package list was extracted into appimageTools to prevent duplication.
* | nix-gitignore: init at v3.0.0 (#46112)Raitis Veinbahs2019-02-18
| | | | | | closes siers/nix-gitignore#6
* | nixpkgs/manual: add trivial builders sectionMatthew Bauer2019-01-26
| | | | | | | | Fixes #25507.
* | nixpkgs/manual: document fetcher functionsMatthew Bauer2019-01-26
|/ | | | Fixes #32439.
* prefer-fetch-remote: an overlay to fetch on remote buildersJörg Thalheim2019-01-18
| | | | | | This is useful when running tools like NixOps or nix-review on workstations where the upload to the builder is significantly slower then downloading the source on the builder itself.
* nixpkgs: Start documenting library functions in XMLGraham Christensen2018-10-05
| | | | | | Covers assert functions and about half of the attrsets functions. Some internal consistency around IDs could be improved.
* shell functions: rewrite as xmlGraham Christensen2018-10-02
|
* nixpkgs docs: move shell section to its own fileGraham Christensen2018-10-02
|
* nixpkgs docs: move dockertool to its own fileGraham Christensen2018-10-02
|
* nixpkgs docs: move fhs-environments to its own fileGraham Christensen2018-10-02
|
* nixpkgs docs: move debug to its own fileGraham Christensen2018-10-02
|
* nixpkgs docs: move generators to its own fileGraham Christensen2018-10-02
|
* nixpkgs docs: move overrides to its own fileGraham Christensen2018-10-02
|
* fixup: drop comment about config behaving differently from buildImageGraham Christensen2018-09-27
|
* dockerTools.buildLayeredImage: initGraham Christensen2018-09-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a many-layered Docker Image. Implements much less than buildImage: - Doesn't support specific uids/gids - Doesn't support runninng commands after building - Doesn't require qemu - Doesn't create mutable copies of the files in the path - Doesn't support parent images If you want those feature, I recommend using buildLayeredImage as an input to buildImage. Notably, it does support: - Caching low level, common paths based on a graph traversial algorithm, see referencesByPopularity in 0a80233487993256e811f566b1c80a40394c03d6 - Configurable number of layers. If you're not using AUFS or not extending the image, you can specify a larger number of layers at build time: pkgs.dockerTools.buildLayeredImage { name = "hello"; maxLayers = 128; config.Cmd = [ "${pkgs.gitFull}/bin/git" ]; }; - Parallelized creation of the layers, improving build speed. - The contents of the image includes the closure of the configuration, so you don't have to specify paths in contents and config. With buildImage, paths referred to by the config were not included automatically in the image. Thus, if you wanted to call Git, you had to specify it twice: pkgs.dockerTools.buildImage { name = "hello"; contents = [ pkgs.gitFull ]; config.Cmd = [ "${pkgs.gitFull}/bin/git" ]; }; buildLayeredImage on the other hand includes the runtime closure of the config when calculating the contents of the image: pkgs.dockerTools.buildImage { name = "hello"; config.Cmd = [ "${pkgs.gitFull}/bin/git" ]; }; Minor Problems - If any of the store paths change, every layer will be rebuilt in the nix-build. However, beacuse the layers are bit-for-bit reproducable, when these images are loaded in to Docker they will match existing layers and not be imported or uploaded twice. Common Questions - Aren't Docker layers ordered? No. People who have used a Dockerfile before assume Docker's Layers are inherently ordered. However, this is not true -- Docker layers are content-addressable and are not explicitly layered until they are composed in to an Image. - What happens if I have more than maxLayers of store paths? The first (maxLayers-2) most "popular" paths will have their own individual layers, then layer #(maxLayers-1) will contain all the remaining "unpopular" paths, and finally layer #(maxLayers) will contain the Image configuration.
* Clarfy the binary reproducibility problems of created=now with ↵Graham Christensen2018-09-20
| | | | dockerTools.buildImage.
* dockerTools.buildImage: support impure datesGraham Christensen2018-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because dates are an impurity, by default buildImage will use a static date of one second past the UNIX Epoch. This can be a bit frustrating when listing docker images in the CLI: $ docker image list REPOSITORY TAG IMAGE ID CREATED SIZE hello latest 08c791c7846e 48 years ago 25.2MB If you want to trade the purity for a better user experience, you can set created to now. pkgs.dockerTools.buildImage { name = "hello"; tag = "latest"; created = "now"; contents = pkgs.hello; config.Cmd = [ "/bin/hello" ]; } and now the Docker CLI will display a reasonable date and sort the images as expected: $ docker image list REPOSITORY TAG IMAGE ID CREATED SIZE hello latest de2bf4786de6 About a minute ago 25.2MB
* Manual: Random indentation fixesEelco Dolstra2018-09-03
|
* nixpkgs docs: normalizeGraham Christensen2018-08-27
|
* docs: include shell sectionGraham Christensen2018-08-27
|
* dockerTools.pullImage: control OS and architectureNick Novitski2018-07-27
|
* dockerTools.buildImage: add option to use nix output hash as tagMathias Schreck2018-07-06
|
* doc: ran `make format`Samuel Dionne-Riel2018-05-31
| | | | With visual inspection that nothing got worse.
* dockerTools.pullImage: documentation and release noteAntoine Eiche2018-05-02
|
* nixpkgs docs: format =)Graham Christensen2018-05-01
|
* docs: initial manual entry for `lib/debug.nix`Profpatsch2018-04-27
| | | | It is more of a stub for now, but at least points to the right file.
* lib/generators: add an example of overriding defaultsProfpatsch2018-03-29
| | | | | An example of overriding the `toINI` generator is added, hopefully clarifying the expressiveness of generators.
* dockerTools: document image spec v1.2 compatibilityMathias Schreck2017-08-03
|
* doc: Fix some typosJan Tojnar2017-06-11
|
* rename iana_etc to iana-etcJörg Thalheim2017-03-28
| | | | fixes #23621
* wrap added notes in <note>Paul Kinsky2017-02-20
|
* Add tips for resolving https issues in containersPaul Kinsky2017-02-20
| | | | I ran into some issues making HTTPS requests from a container built with buildImage. I've added notes with tips for resolving similar issues.
* ~/.nixpkgs -> ~/.config/nixpkgsEelco Dolstra2017-02-01
| | | | | | The former is still respected as a fallback for config.nix for backwards compatibility (but not for overlays because they're a new feature).
* Add overlays mechanism to Nixpkgs.Nicolas B. Pierron2017-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch add a new argument to Nixpkgs default expression named "overlays". By default, the value of the argument is either taken from the environment variable `NIXPKGS_OVERLAYS`, or from the directory `~/.nixpkgs/overlays/`. If the environment variable does not name a valid directory then this mechanism would fallback on the home directory. If the home directory does not exists it will fallback on an empty list of overlays. The overlays directory should contain the list of extra Nixpkgs stages which would be used to extend the content of Nixpkgs, with additional set of packages. The overlays, i-e directory, files, symbolic links are used in alphabetical order. The simplest overlay which extends Nixpkgs with nothing looks like: ```nix self: super: { } ``` More refined overlays can use `super` as the basis for building new packages, and `self` as a way to query the final result of the fix-point. An example of overlay which extends Nixpkgs with a small set of packages can be found at: https://github.com/nbp/nixpkgs-mozilla/blob/nixpkgs-overlay/moz-overlay.nix To use this file, checkout the repository and add a symbolic link to the `moz-overlay.nix` file in `~/.nixpkgs/overlays` directory.
* docs: fix a couple of unmatched parenthesesKier Davis2017-01-12
|
* lib/generators: add manual documentationProfpatsch2016-11-17
| | | | Restructures the functions reference a bit.
* Merge pull request #18660 from aneeshusa/add-override-attrsDomen Kožar2016-10-30
|\ | | | | mkDerivation: add overrideAttrs function
| * mkDerivation: add overrideAttrs functionAneesh Agrawal2016-10-02
| | | | | | | | | | | | | | | | | | This is similar to `overrideDerivation`, but overrides the arguments to `mkDerivation` instead of the underlying `derivation` call. Also update `makeOverridable` so that uses of `overrideAttrs` can be followed by `override` and `overrideDerivation`, i.e. they can be mix-and-matched.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-05-16 09:11:58 +0000