summary refs log tree commit diff
path: root/doc
Commit message (Collapse)AuthorAge
* coqPackages: update documentation to mention coq.ocamlPackages attributeThéo Zimmermann2018-10-19
|
* Merge pull request #48463 from Ekleog/release-notes-licenseGraham Christensen2018-10-15
|\ | | | | release-notes/18-09: add licenses marked as unfree
| * package-notes: line wrap by auto-cleanupLéo Gaspard2018-10-15
| |
* | nixpkgs docs: document recursivelyUpdateGraham Christensen2018-10-12
| |
* | nixpkgs docs: document recursivelyUpdateUntilGraham Christensen2018-10-12
| |
* | nixpkgs docs: document zipAttrsGraham Christensen2018-10-12
| |
* | nixpkgs docs: document zipAttrsWithGraham Christensen2018-10-12
| |
* | nixpkgs docs: Clarify zipAttrsWithNames's docsGraham Christensen2018-10-12
| |
* | nixpkgs docs: document zipAttrsWithNamesGraham Christensen2018-10-12
| |
* | nixpkgs docs: document optionalAttrsGraham Christensen2018-10-12
| |
* | nixpkgs docs: document toDerivationGraham Christensen2018-10-12
| |
* | nixpkgs docs: document isDerivationGraham Christensen2018-10-12
| |
* | nixpkgs docs: document genAttrsGraham Christensen2018-10-12
| |
* | nixpkgs docs: document mapAttrsRecursiveCondGraham Christensen2018-10-12
| |
* | nixpkgs docs: finish up mapAttrsRecursiveGraham Christensen2018-10-12
|/
* Update with code review feedback; add example python applicationBenjamin Hipple2018-10-12
|
* python: update documentationBenjamin Hipple2018-10-12
| | | | | | | | | | This touches up a handful of places in the python documentation to try to make the current best-practices more obvious. In particular, I often find the function signatures (what to pass, what not to pass) confusing and have added them to the docs. Also updated the metas to be more consistent with the most frequently used modern style.
* Generate links to function definitionsGraham Christensen2018-10-05
| | | | | | | | | | Hydra passes the full revision in to the input, which we pass through. If we don't get this ,we try to get it from other sources, or default to master which should have the definition in a close-ish location. All published docs should have theURL resolve properly, only local hackers will have the link break.
* 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.
* Merge pull request #47688 from grahamc/doc-breakout-functionsGraham Christensen2018-10-03
|\ | | | | nixpkgs docs: breakout functions
| * nixpkgs docs: ReformatGraham Christensen2018-10-02
| |
| * nixpkgs docs: Rebuild manual-full if nested XML docs changeGraham Christensen2018-10-02
| |
| * 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
| |
* | Merge pull request #47455 from nyanloutre/steamPackages.steam-udevJörg Thalheim2018-10-02
|\ \ | |/ |/| steamPackages.steam: add udev rules and update to 1.0.0.56
| * nixos/steam-hardware: update documentationnyanloutre2018-09-30
| |
* | Merge pull request #47411 from graham-at-target/multi-layered-images-craftedlewo2018-10-01
|\ \ | |/ |/| Multi-Layered Docker Images
| * 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.
* | Merge pull request #47238 from obsidiansystems/overrideScope-orderJohn Ericson2018-09-24
|\ \ | |/ |/| lib: Deprecate `overrideScope` in lieu of `overrideScope'` taking arguments in the conventional order
| * lib: Make `overrideScope'` which takes arguments in the conventional orderJohn Ericson2018-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `overrideScope` bound by `makeScope` (via special `callPackage`) took an override in the form `super: self { … }`. But this is dangerously close to the `self: super { … }` form used by *everything* else, even other definitions of `overrideScope`! Since that implementation did not even share any code either until I changed it recently in 3cf43547f4be03d1d6eb0bbfc557e2dbc13b4095, this inconsistency is almost certainly an oversight and not intentional. Unfortunately, just as the inconstency is hard to debug if one just assumes the conventional order, any sudden fix would break existing overrides in the same hard-to-debug way. So instead of changing the definition a new `overrideScope'` with the conventional order is added, and old `overrideScope` deprecated with a warning saying to use `overrideScope'` instead. That will hopefully get people to stop using `overrideScope`, freeing our hand to change or remove it in the future.
* | doc: Don't mention top-level `{build, host, target}Platform`John Ericson2018-09-23
| | | | | | | | | | | | | | | | For technical reasons, we cannot easily add a warning to top-level definitions, so 2a6e4ae49a891adc7c0562fda08b17d60beb1b4f and e51f736076548459f36a1250de4bf6867f880b66 reverted the deprecation. But we can still remove mention of the would-be deprecated definitions to steer people towards using the preferred alternatives.
* | Clarfy the binary reproducibility problems of created=now with ↵Graham Christensen2018-09-20
| | | | | | | | dockerTools.buildImage.
* | doc/stdenv: libaries -> libraries (#47011)John Children2018-09-20
| | | | | | | | This commit corrects a minor typo in the stdenv portion of the documentation for the nix language.
* | 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
* | doc/vim: remove some vim-plug redundancyJörg Thalheim2018-09-20
| |
* | doc: Add section about vim-plugRoman Volosatovs2018-09-20
| |
* | ibus-engines.typing-booster: init at 2.1.1Maximilian Bosch2018-09-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This package providesa completion input method for faster typing. See https://mike-fabian.github.io/ibus-typing-booster Detailed instructions how to activate this IBus engine on your desktop can be found in the upstream docs: https://mike-fabian.github.io/ibus-typing-booster/documentation.html A simple VM with the Gnome3 desktop and activated `ibus' looks like this: ```nix { emojipicker = { pkgs, ... }: { services.xserver = { enable = true; desktopManager.gnome3.enable = true; desktopManager.xterm.enable = false; }; users.extraUsers.vm = { password = "vm"; isNormalUser = true; }; i18n.inputMethod.ibus.engines = [ pkgs.ibus-engines.typing-booster ]; i18n.inputMethod.enabled = "ibus"; virtualisation.memorySize = 2048; }; } ``` Fixes #38721
* | rust.section.md: remove nixcrate referenceworldofpeace2018-09-15
| | | | | | nixcrate is deprecated
* | Revert "top-level: Deprecate top-level `{build,host,target}Platform`"Sarah Brofeldt2018-09-11
| | | | | | | | This reverts commit e51f736076548459f36a1250de4bf6867f880b66.
* | vim-plugins: rewrite updaterJörg Thalheim2018-09-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A new python script has been added to replace the aged viml-based updater. The new updater has the following advantages: - use rss feeds to check for updates quicker - parallel downloads & better caching - uses proper override mechanism instead of text substitution - update generated files in-place instead of having to insert updated plugins manually Automatically reading `dependencies` from the plugins directory has been not re-implemented. This has been mostly been used by Mark Weber's plugins, which seem to no longer receive regular updates. This could be implemented in future as required.
* | doc/vim: improve plugin documentationJörg Thalheim2018-09-09
| |
* | Merge pull request #45728 from Ma27/nixos/weechat-moduleTimo Kaufmann2018-09-07
|\ \ | | | | | | nixos/weechat: add module
| * | weechat: 2.1 -> 2.2; improve package configurationMaximilian Bosch2018-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This aims to make the `weechat` package even more configurable. It allows to specify scripts and commands using the `configure` function inside a `weechat.override` expression. The package can be configured like this: ``` with import <nixpkgs> { }; weechat.override { plugins = { availablePlugins, ... }: { plugins = builtins.attrValues availablePlugins; init = '' /set foo bar /server add freenode chat.freenode.org ''; scripts = [ "/path/to/script.py" ]; }; } ``` All commands are passed to `weechat --run-command "/set foo bar;/server ..."`. The `plugins' attribute is not necessarily required anymore, if it's sufficient to add `init' commands, the `plugins' will be `builtins.attrValues availablePlugins' by default. Additionally the result contains `weechat` and `weechat-headless` (introduced in WeeChat 2.1) now.
* | | Merge pull request #46059 from ↵John Ericson2018-09-06
|\ \ \ | |/ / |/| / | |/ | | obsidiansystems/deprecate-top-level-platform-aliases top-level: Deprecate top-level `{build,host,target}Platform`
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-06-29 00:03:26 +0000