| Commit message (Expand) | Author | Age | Files | Lines |
|---|
| * | doc/functions/generators: convert to CommonMark | Ryan Mulligan | 2021-06-11 | 1 | -1/+1 |
| * | doc/functions/prefer-remote-fetch: convert to CommonMark | Ryan Mulligan | 2021-06-07 | 1 | -1/+1 |
| * | doc/functions/debug: convert to CommonMark | Ryan Mulligan | 2021-06-07 | 1 | -1/+1 |
| * | doc: nix-gitignore to CommonMark•••Closes #125670
| Antoine Martin | 2021-06-05 | 1 | -1/+1 |
| * | doc: move fhs and mkShell under builders/special•••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...
| Frederik Rietdijk | 2019-10-21 | 1 | -2/+0 |
| * | doc: move overrides into separate chapter | Frederik Rietdijk | 2019-10-21 | 1 | -1/+0 |
| * | doc: move image builders into new images chapter | Frederik Rietdijk | 2019-10-21 | 1 | -4/+0 |
| * | doc: move fetchers and trivial builders under builders | Frederik Rietdijk | 2019-10-20 | 1 | -2/+0 |
| * | doc: re-format | Jan Tojnar | 2019-09-18 | 1 | -2/+1 |
| * | ociTools: init | Katharina Fey | 2019-09-04 | 1 | -0/+1 |
| * | snapTools.makeSnap: init | Graham Christensen | 2019-06-18 | 1 | -0/+1 |
| * | Merge pull request #54693 from tilpner/appimage-tools•••appimageTools: init | Graham Christensen | 2019-02-23 | 1 | -0/+1 |
| |\ |
|
| | * | appimageTools: init•••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.
| tilpner | 2019-02-23 | 1 | -0/+1 |
| * | | nix-gitignore: init at v3.0.0 (#46112)•••closes siers/nix-gitignore#6 | Raitis Veinbahs | 2019-02-18 | 1 | -0/+1 |
| * | | nixpkgs/manual: add trivial builders section•••Fixes #25507.
| Matthew Bauer | 2019-01-26 | 1 | -0/+1 |
| * | | nixpkgs/manual: document fetcher functions•••Fixes #32439.
| Matthew Bauer | 2019-01-26 | 1 | -0/+1 |
| |/ |
|
| * | prefer-fetch-remote: an overlay to fetch on remote builders•••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.
| Jörg Thalheim | 2019-01-18 | 1 | -0/+1 |
| * | nixpkgs: Start documenting library functions in XML•••Covers assert functions and about half of the attrsets functions.
Some internal consistency around IDs could be improved.
| Graham Christensen | 2018-10-05 | 1 | -1/+1 |
| * | shell functions: rewrite as xml | Graham Christensen | 2018-10-02 | 1 | -1/+1 |
| * | nixpkgs docs: move shell section to its own file | Graham Christensen | 2018-10-02 | 1 | -1/+1 |
| * | nixpkgs docs: move dockertool to its own file | Graham Christensen | 2018-10-02 | 1 | -563/+1 |
| * | nixpkgs docs: move fhs-environments to its own file | Graham Christensen | 2018-10-02 | 1 | -141/+1 |
| * | nixpkgs docs: move debug to its own file | Graham Christensen | 2018-10-02 | 1 | -18/+1 |
| * | nixpkgs docs: move generators to its own file | Graham Christensen | 2018-10-02 | 1 | -87/+1 |
| * | nixpkgs docs: move overrides to its own file | Graham Christensen | 2018-10-02 | 1 | -201/+1 |
| * | fixup: drop comment about config behaving differently from buildImage | Graham Christensen | 2018-09-27 | 1 | -6/+0 |
| * | dockerTools.buildLayeredImage: init•••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.
| Graham Christensen | 2018-09-26 | 1 | -0/+177 |
| * | Clarfy the binary reproducibility problems of created=now with dockerTools.bu... | Graham Christensen | 2018-09-20 | 1 | -9/+12 |
| * | dockerTools.buildImage: support impure dates•••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
| Graham Christensen | 2018-09-20 | 1 | -0/+39 |
| * | Manual: Random indentation fixes | Eelco Dolstra | 2018-09-03 | 1 | -70/+80 |
| * | nixpkgs docs: normalize | Graham Christensen | 2018-08-27 | 1 | -15/+16 |
| * | docs: include shell section | Graham Christensen | 2018-08-27 | 1 | -0/+2 |
| * | dockerTools.pullImage: control OS and architecture | Nick Novitski | 2018-07-27 | 1 | -2/+22 |
| * | dockerTools.buildImage: add option to use nix output hash as tag | Mathias Schreck | 2018-07-06 | 1 | -1/+1 |
| * | doc: ran `make format`•••With visual inspection that nothing got worse.
| Samuel Dionne-Riel | 2018-05-31 | 1 | -20/+28 |
| * | dockerTools.pullImage: documentation and release note | Antoine Eiche | 2018-05-02 | 1 | -34/+21 |
| * | nixpkgs docs: format =) | Graham Christensen | 2018-05-01 | 1 | -532/+538 |
| * | docs: initial manual entry for `lib/debug.nix`•••It is more of a stub for now, but at least points to the right file.
| Profpatsch | 2018-04-27 | 1 | -0/+16 |
| * | lib/generators: add an example of overriding defaults•••An example of overriding the `toINI` generator is added,
hopefully clarifying the expressiveness of generators.
| Profpatsch | 2018-03-29 | 1 | -4/+57 |
| * | dockerTools: document image spec v1.2 compatibility | Mathias Schreck | 2017-08-03 | 1 | -4/+4 |
| * | doc: Fix some typos | Jan Tojnar | 2017-06-11 | 1 | -1/+1 |
| * | rename iana_etc to iana-etc•••fixes #23621
| Jörg Thalheim | 2017-03-28 | 1 | -1/+1 |
| * | wrap added notes in <note> | Paul Kinsky | 2017-02-20 | 1 | -5/+10 |
| * | Add tips for resolving https issues in containers•••I ran into some issues making HTTPS requests from a container built with buildImage. I've added notes with tips for resolving similar issues.
| Paul Kinsky | 2017-02-20 | 1 | -0/+11 |
| * | ~/.nixpkgs -> ~/.config/nixpkgs•••The former is still respected as a fallback for config.nix for
backwards compatibility (but not for overlays because they're a new
feature).
| Eelco Dolstra | 2017-02-01 | 1 | -1/+1 |
| * | Add overlays mechanism to Nixpkgs.•••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.
| Nicolas B. Pierron | 2017-01-16 | 1 | -62/+2 |
| * | docs: fix a couple of unmatched parentheses | Kier Davis | 2017-01-12 | 1 | -2/+2 |
| * | lib/generators: add manual documentation•••Restructures the functions reference a bit.
| Profpatsch | 2016-11-17 | 1 | -345/+388 |
| * | Merge pull request #18660 from aneeshusa/add-override-attrs•••mkDerivation: add overrideAttrs function | Domen Kožar | 2016-10-30 | 1 | -0/+61 |
| |\ |
|
| | * | mkDerivation: add overrideAttrs function•••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.
| Aneesh Agrawal | 2016-10-02 | 1 | -0/+61 |
