jiebi/CodeConvo huggingface dataset:
<ins> # Customising Packages {#sec-customising-packages} Some packages in Nixpkgs have options to enable or disable optional functionality or change other aspects of the package. For instance, the Firefox wrapper package (which provides Firefox with a set of plugins such as the Adobe Flash player) has an option to enable the Google Talk plugin. It can be set in `configuration.nix` as follows: `nixpkgs.config.firefox.enableGoogleTalkPlugin = true;` ::: {.warning} Unfortunately, Nixpkgs currently lacks a way to query available configuration options. ::: Apart from high-level options, it's possible to tweak a package in almost arbitrary ways, such as changing or disabling dependencies of a package. For instance, the Emacs package in Nixpkgs by default has a dependency on GTK 2. If you want to build it against GTK 3, you can specify that as follows: ```nix environment.systemPackages = [ (pkgs.emacs.override { gtk = pkgs.gtk3; }) ]; ``` The function `override` performs the call to the Nix function that produces Emacs, with the original arguments amended by the set of arguments specified by you. So here the function argument `gtk` gets the value `pkgs.gtk3`, causing Emacs to depend on GTK 3. (The parentheses are necessary because in Nix, function application binds more weakly than list construction, so without them, [](#opt-environment.systemPackages) would be a list with two elements.) Even greater customisation is possible using the function `overrideAttrs`. While the `override` mechanism above overrides the arguments of a package function, `overrideAttrs` allows changing the *attributes* passed to `mkDerivation`. This permits changing any aspect of the package, such as the source code. For instance, if you want to override the source code of Emacs, you can say: ```nix environment.systemPackages = [ (pkgs.emacs.overrideAttrs (oldAttrs: { name = "emacs-25.0-pre"; src = /path/to/my/emacs/tree; })) ]; ``` Here, `overrideAttrs` takes the Nix derivation specified by `pkgs.emacs` and produces a new derivation in which the original's `name` and `src` attribute have been replaced by the given values by re-calling `stdenv.mkDerivation`. The original attributes are accessible via the function argument, which is conventionally named `oldAttrs`. The overrides shown above are not global. They do not affect the original package; other packages in Nixpkgs continue to depend on the original rather than the customised package. This means that if another package in your system depends on the original package, you end up with two instances of the package. If you want to have everything depend on your customised instance, you can apply a *global* override as follows: ```nix nixpkgs.config.packageOverrides = pkgs: { emacs = pkgs.emacs.override { gtk = pkgs.gtk3; }; }; ``` The effect of this definition is essentially equivalent to modifying the `emacs` attribute in the Nixpkgs source tree. Any package in Nixpkgs that depends on `emacs` will be passed your customised instance. (However, the value `pkgs.emacs` in `nixpkgs.config.packageOverrides` refers to the original rather than overridden instance, to prevent an infinite recursion.) </ins>
<command>nixos-rebuild switch</command>. </para> <del> <xi:include href="customizing-packages.xml" /> </del> <ins> <xi:include href="../from_md/configuration/customizing-packages.section.xml" /> </ins> <del> <xi:include href="adding-custom-packages.xml" /> </del> <ins> <xi:include href="../from_md/configuration/adding-custom-packages.section.xml" /> </ins> </section>
<ins> <section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-custom-packages"> <title>Adding Custom Packages</title> <para> It’s possible that a package you need is not available in NixOS. In that case, you can do two things. First, you can clone the Nixpkgs repository, add the package to your clone, and (optionally) submit a patch or pull request to have it accepted into the main Nixpkgs repository. This is described in detail in the <link xlink:href="https://nixos.org/nixpkgs/manual">Nixpkgs manual</link>. In short, you clone Nixpkgs: </para> <programlisting> $ git clone https://github.com/NixOS/nixpkgs $ cd nixpkgs </programlisting> <para> Then you write and test the package as described in the Nixpkgs manual. Finally, you add it to <xref linkend="opt-environment.systemPackages" />, e.g. </para> <programlisting language="bash"> environment.systemPackages = [ pkgs.my-package ]; </programlisting> <para> and you run <literal>nixos-rebuild</literal>, specifying your own Nixpkgs tree: </para> <programlisting> # nixos-rebuild switch -I nixpkgs=/path/to/my/nixpkgs </programlisting> <para> The second possibility is to add the package outside of the Nixpkgs tree. For instance, here is how you specify a build of the <link xlink:href="https://www.gnu.org/software/hello/">GNU Hello</link> package directly in <literal>configuration.nix</literal>: </para> <programlisting language="bash"> environment.systemPackages = let my-hello = with pkgs; stdenv.mkDerivation rec { name = &quot;hello-2.8&quot;; src = fetchurl { url = &quot;mirror://gnu/hello/${name}.tar.gz&quot;; sha256 = &quot;0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6&quot;; }; }; in [ my-hello ]; </programlisting> <para> Of course, you can also move the definition of <literal>my-hello</literal> into a separate Nix expression, e.g. </para> <programlisting language="bash"> environment.systemPackages = [ (import ./my-hello.nix) ]; </programlisting> <para> where <literal>my-hello.nix</literal> contains: </para> <programlisting language="bash"> with import &lt;nixpkgs&gt; {}; # bring all of Nixpkgs into scope stdenv.mkDerivation rec { name = &quot;hello-2.8&quot;; src = fetchurl { url = &quot;mirror://gnu/hello/${name}.tar.gz&quot;; sha256 = &quot;0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6&quot;; }; } </programlisting> <para> This allows testing the package easily: </para> <programlisting> $ nix-build my-hello.nix $ ./result/bin/hello Hello, world! </programlisting> </section> </ins>
${optionalString cfg.userControlled.enable '' ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=${cfg.userControlled.group} update_config=1''} <del> ${concatStringsSep "n" (mapAttrsToList (ssid: networkConfig: '' </del> <ins> ${concatStringsSep "n" (mapAttrsToList (ssid: networkConfig: let psk = if networkConfig.psk != null then ''"${networkConfig.psk}"'' else networkConfig.pskRaw; in '' </ins> network={ ssid="${ssid}" <del> ${optionalString (networkConfig.psk != null) ''psk="${networkConfig.psk}"''} ${optionalString (networkConfig.psk == null) ''key_mgmt=NONE''} </del> <ins> ${optionalString (psk != null) ''psk=${psk}''} ${optionalString (psk == null) ''key_mgmt=NONE''} </ins> } '') cfg.networks)} '' else "/etc/wpa_supplicant.conf";
Be aware that these will be written to the nix store in plaintext! <ins> Mutually exclusive with <varname>pskRaw</varname>. ''; }; pskRaw = mkOption { type = types.nullOr types.str; default = null; description = '' The network's pre-shared key in hex defaulting to being a network without any authentication. Mutually exclusive with <varname>psk</varname>. </ins> ''; }; };
config = mkMerge [ (mkIf cfg.enable { <ins> assertions = flip mapAttrsToList cfg.networks (name: cfg: { assertion = cfg.psk == null || cfg.pskRaw == null; message = ''networking.wireless."${name}".psk and networking.wireless."${name}".pskRaw are mutually exclusive''; }); </ins> environment.systemPackages =  [ pkgs.wpa_supplicant ]; services.dbus.packages = [ pkgs.wpa_supplicant ];
source $stdenv/setup ``` <del> to let `stdenv` set up the environment (e.g., process the `buildInputs`). If you want, you can still use `stdenv`’s generic builder: </del> <ins> to let `stdenv` set up the environment (e.g. by resetting `PATH` and populating it from build inputs). If you want, you can still use `stdenv`’s generic builder: </ins> ```bash source $stdenv/setup
### The fixup phase {#ssec-fixup-phase} <del> The fixup phase performs some (Nix-specific) post-processing actions on the files installed under `$out` by the install phase. The default `fixupPhase` does the following: </del> <ins> The fixup phase performs (Nix-specific) post-processing actions on the files installed under `$out` by the install phase. The default `fixupPhase` does the following: </ins> - It moves the `man/`, `doc/` and `info/` subdirectories of `$out` to `share/`. - It strips libraries and executables of debug information. - On Linux, it applies the `patchelf` command to ELF executables and libraries to remove unused directories from the `RPATH` in order to prevent unnecessary runtime dependencies. <del> - It rewrites the interpreter paths of shell scripts to paths found in `PATH`. E.g., `/usr/bin/perl` will be rewritten to `/nix/store/some-perl/bin/perl` found in `PATH`. </del> <ins> - It rewrites the interpreter paths of shell scripts to paths found in `PATH`. E.g., `/usr/bin/perl` will be rewritten to `/nix/store/some-perl/bin/perl` found in `PATH`. See [](#patch-shebangs.sh) for details. </ins> #### Variables controlling the fixup phase {#variables-controlling-the-fixup-phase}
##### `dontPatchShebangs` {#var-stdenv-dontPatchShebangs} <del> If set, scripts starting with `#!` do not have their interpreter paths rewritten to paths in the Nix store. </del> <ins> If set, scripts starting with `#!` do not have their interpreter paths rewritten to paths in the Nix store. See [](#patch-shebangs.sh) on how patching shebangs works. </ins> ##### `dontPruneLibtoolFiles` {#var-stdenv-dontPruneLibtoolFiles}
The *existence* of setups hooks has long been documented and packages inside Nixpkgs are free to use this mechanism. Other packages, however, should not rely on these mechanisms not changing between Nixpkgs versions. Because of the existing issues with this system, there’s little benefit from mandating it be stable for any period of time. <del> First, let’s cover some setup hooks that are part of Nixpkgs default stdenv. This means that they are run for every package built using `stdenv.mkDerivation`. Some of these are platform specific, so they may run on Linux but not Darwin or vice-versa. </del> <ins> First, let’s cover some setup hooks that are part of Nixpkgs default `stdenv`. This means that they are run for every package built using `stdenv.mkDerivation` or when using a custom builder that has `source $stdenv/setup`. Some of these are platform specific, so they may run on Linux but not Darwin or vice-versa. </ins> ### `move-docs.sh` {#move-docs.sh}
### `patch-shebangs.sh` {#patch-shebangs.sh} <del> This setup hook patches installed scripts to use the full path to the shebang interpreter. A shebang interpreter is the first commented line of a script telling the operating system which program will run the script (e.g `#!/bin/bash`). In Nix, we want an exact path to that interpreter to be used. This often replaces `/bin/sh` with a path in the Nix store. </del> <ins> This setup hook patches installed scripts to add Nix store paths to their shebang interpreter as found in the build environment. The [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) line tells a Unix-like operating system which interpreter to use to execute the script's contents. ::: note The [generic builder][generic-builder] populates `PATH` from inputs of the derivation. ::: [generic-builder]: https://github.com/NixOS/nixpkgs/blob/19d4f7dc485f74109bd66ef74231285ff797a823/pkgs/stdenv/generic/builder.sh #### Invocation {#patch-shebangs.sh-invocation} Multiple paths can be specified. ``` patchShebangs [--build | --host] PATH... ``` ##### Flags `--build` : Look up commands available at build time `--host` : Look up commands available at run time ##### Examples ```sh patchShebangs --host /nix/store/<hash>-hello-1.0/bin ``` ```sh patchShebangs --build configure ``` `#!/bin/sh` will be rewritten to `#!/nix/store/<hash>-some-bash/bin/sh`. `#!/usr/bin/env` gets special treatment: `#!/usr/bin/env python` is rewritten to `/nix/store/<hash>/bin/python`. Interpreter paths that point to a valid Nix store location are not changed. ::: note A script file must be marked as executable, otherwise it will not be considered. ::: This mechanism ensures that the interpreter for a given script is always found and is exactly the one specified by the build. It can be disabled by setting [`dontPatchShebangs`](#var-stdenv-dontPatchShebangs): ```nix stdenv.mkDerivation { # ... dontPatchShebangs = true; # ... } ``` The file [`patch-shebangs.sh`][patch-shebangs.sh] defines the [`patchShebangs`][patchShebangs] function. It is used to implement [`patchShebangsAuto`][patchShebangsAuto], the [setup hook](#ssec-setup-hooks) that is registered to run during the [fixup phase](#ssec-fixup-phase) by default. If you need to run `patchShebangs` at build time, it must be called explicitly within [one of the build phases](#sec-stdenv-phases). [patch-shebangs.sh]: https://github.com/NixOS/nixpkgs/blob/19d4f7dc485f74109bd66ef74231285ff797a823/pkgs/build-support/setup-hooks/patch-shebangs.sh [patchShebangs]: https://github.com/NixOS/nixpkgs/blob/19d4f7dc485f74109bd66ef74231285ff797a823/pkgs/build-support/setup-hooks/patch-shebangs.sh#L24-L105 [patchShebangsAuto]: https://github.com/NixOS/nixpkgs/blob/19d4f7dc485f74109bd66ef74231285ff797a823/pkgs/build-support/setup-hooks/patch-shebangs.sh#L107-L119 </ins> ### `audit-tmpdir.sh` {#audit-tmpdir.sh}
[^footnote-stdenv-ignored-build-platform]: The build platform is ignored because it is a mere implementation detail of the package satisfying the dependency: As a general programming principle, dependencies are always *specified* as interfaces, not concrete implementation. [^footnote-stdenv-native-dependencies-in-path]: Currently, this means for native builds all dependencies are put on the `PATH`. But in the future that may not be the case for sake of matching cross: the platforms would be assumed to be unique for native and cross builds alike, so only the `depsBuild*` and `nativeBuildInputs` would be added to the `PATH`. <del> [^footnote-stdenv-propagated-dependencies]: Nix itself already takes a package’s transitive dependencies into account, but this propagation ensures nixpkgs-specific infrastructure like setup hooks (mentioned above) also are run as if the propagated dependency. </del> <ins> [^footnote-stdenv-propagated-dependencies]: Nix itself already takes a package’s transitive dependencies into account, but this propagation ensures nixpkgs-specific infrastructure like [setup hooks](#ssec-setup-hooks) also are run as if it were a propagated dependency. </ins> [^footnote-stdenv-find-inputs-location]: The `findInputs` function, currently residing in `pkgs/stdenv/generic/setup.sh`, implements the propagation logic. [^footnote-stdenv-sys-lib-search-path]: It clears the `sys_lib_*search_path` variables in the Libtool script to prevent Libtool from using libraries in `/usr/lib` and such. [^footnote-stdenv-build-time-guessing-impurity]: Eventually these will be passed building natively as well, to improve determinism: build-time guessing, as is done today, is a risk of impurity.
<ins> { lib, fetchFromGitHub, python3Packages, wrapGAppsHook, gobject-introspection, gtk3, keybinder3, xdotool, pango, gdk-pixbuf, atk, librsvg }: python3Packages.buildPythonApplication rec { pname = "emote"; version = "2.0.0"; src = fetchFromGitHub { owner = "tom-james-watson"; repo = "Emote"; rev = "v${version}"; sha256 = "kYXFD6VBnuEZ0ZMsF6ZmN4V0JN83puxRILpNlllVsKQ="; }; postPatch = '' substituteInPlace setup.py --replace "pygobject==3.36.0" "pygobject" substituteInPlace emote/config.py --replace 'os.environ.get("SNAP")' "'$out/share/emote'" substituteInPlace snap/gui/emote.desktop --replace "Icon=''${SNAP}/usr/share/icons/emote.svg" "Icon=emote.svg" ''; nativeBuildInputs = [ wrapGAppsHook gobject-introspection keybinder3 pango gdk-pixbuf atk ]; propagatedBuildInputs = [ python3Packages.pygobject3 gtk3 xdotool librsvg ]; postInstall = '' install -D snap/gui/emote.desktop $out/share/applications/emote.desktop install -D snap/gui/emote.svg $out/share/pixmaps/emote.svg install -D -t $out/share/emote/static static/{emojis.json,logo.svg,style.css} ''; dontWrapGApps = true; preFixup = '' makeWrapperArgs+=("''${gappsWrapperArgs[@]}") ''; doCheck = false; meta = with lib; { description = "A modern emoji picker for Linux"; homepage = "https://github.com/tom-james-watson/emote"; license = licenses.gpl3Plus; maintainers = with maintainers; [ angustrau ]; platforms = platforms.linux; }; } </ins>
<del> { lib , buildPythonApplication , fetchPypi , appdirs , attrs , beautifulsoup4 , click-plugins , elasticsearch , flask-compress , flask_login , flask_wtf , html2text , python-dotenv , python-frontmatter , requests , tinydb , validators , werkzeug , wtforms }: </del> <ins> { lib, stdenv, python3, fetchPypi }: let defaultOverrides = [ (self: super: { flask = super.flask.overridePythonAttrs (oldAttrs: rec { version = "1.1.2"; pname = "Flask"; src = super.fetchPypi { inherit pname version; sha256 = "sha256-Tvoa4tfJhlr0iYbeiuuFBL8yx/PW/ck1PTSyH0sScGA="; }; checkInputs = [ self.pytest ]; propagatedBuildInputs = with self; [ itsdangerous click werkzeug jinja2 ]; doCheck = false; }); }) (self: super: { flask_login = super.flask_login.overridePythonAttrs (oldAttrs: rec { pname = "Flask"; version = "0.5.0"; src = fetchPypi { inherit pname version; sha256 = "6d33aef15b5bcead780acc339464aae8a6e28f13c90d8b1cf9de8b549d1c0b4b"; }; doCheck = false; }); }) ]; mkOverride = attrname: version: sha256: self: super: { ${attrname} = super.${attrname}.overridePythonAttrs (oldAttrs: { inherit version; src = oldAttrs.src.override { inherit version sha256; }; }); }; py = python3.override { # Put packageOverrides at the start so they are applied after defaultOverrides packageOverrides = lib.foldr lib.composeExtensions (self: super: { }) (defaultOverrides); }; in with py.pkgs; </ins> buildPythonApplication rec { pname = "archivy";
--replace 'validators ==' 'validators >='  --replace 'tinydb ==' 'tinydb >='  --replace 'Flask_WTF == 0.14.3' 'Flask_WTF'  <del> --replace 'Werkzeug ==' 'Werkzeug >='  --replace 'Flask ==' 'Flask >=' </del> <ins> --replace 'Werkzeug ==' 'Werkzeug >=' </ins> ''; propagatedBuildInputs = [
glibcLocales ]; <ins> # as of 2021-07, the gobject-introspection setup hook does not # work with `strictDeps` enabled, thus for proper `wrapGAppsHook` # it needs to be disabled explicitly. https://github.com/NixOS/nixpkgs/issues/56943 strictDeps = false; </ins> buildInputs = [ python3 <ins> gtk3 </ins> gobject-introspection gnome.adwaita-icon-theme ];
checkConfigError 'infinite recursion encountered' config.foo ./freeform-attrsOf.nix ./freeform-unstr-dep-str.nix checkConfigError 'The option .* is used but not defined' config.foo ./freeform-lazyAttrsOf.nix ./freeform-unstr-dep-str.nix checkConfigOutput '^"24"$' config.foo ./freeform-lazyAttrsOf.nix ./freeform-unstr-dep-str.nix ./define-value-string.nix <ins> # submodules in freeformTypes should have their locations annotated checkConfigOutput '/freeform-submodules.nix"$' config.fooDeclarations.0 ./freeform-submodules.nix # freeformTypes can get merged using `types.type`, including submodules checkConfigOutput '^10$' config.free.xxx.foo ./freeform-submodules.nix checkConfigOutput '^10$' config.free.yyy.bar ./freeform-submodules.nix </ins> ## types.anything # Check that attribute sets are merged recursively
checkConfigError "The option .multiple. is defined multiple times" config.multiple ./raw.nix checkConfigOutput "bar" config.priorities ./raw.nix <ins> # Test that types.optionType merges types correctly checkConfigOutput '^10$' config.theOption.int ./optionTypeMerging.nix checkConfigOutput '^"hello"$' config.theOption.str ./optionTypeMerging.nix # Test that types.optionType correctly annotates option locations checkConfigError 'The option .theOption.nested. in .other.nix. is already declared in .optionTypeFile.nix.' config.theOption.nested ./optionTypeFile.nix </ins> cat <<EOF ====== module tests ====== $pass Pass
<ins> { lib, options, ... }: with lib.types; { options.fooDeclarations = lib.mkOption { default = (options.free.type.getSubOptions [])._freeformOptions.foo.declarations; }; options.free = lib.mkOption { type = submodule { config._module.freeformType = lib.mkMerge [ (attrsOf (submodule { options.foo = lib.mkOption {}; })) (attrsOf (submodule { options.bar = lib.mkOption {}; })) ]; }; }; config.free.xxx.foo = 10; config.free.yyy.bar = 10; } </ins>
<ins> { config, lib, ... }: { _file = "optionTypeFile.nix"; options.theType = lib.mkOption { type = lib.types.optionType; }; options.theOption = lib.mkOption { type = config.theType; default = {}; }; config.theType = lib.mkMerge [ (lib.types.submodule { options.nested = lib.mkOption { type = lib.types.int; }; }) (lib.types.submodule { _file = "other.nix"; options.nested = lib.mkOption { type = lib.types.str; }; }) ]; } </ins>
<ins> { config, lib, ... }: { options.theType = lib.mkOption { type = lib.types.optionType; }; options.theOption = lib.mkOption { type = config.theType; }; config.theType = lib.mkMerge [ (lib.types.submodule { options.int = lib.mkOption { type = lib.types.int; default = 10; }; }) (lib.types.submodule { options.str = lib.mkOption { type = lib.types.str; }; }) ]; config.theOption.str = "hello"; } </ins>
modules = toList modules; }; <ins> # The type of a type! optionType = mkOptionType { name = "optionType"; description = "optionType"; check = value: value._type or null == "option-type"; merge = loc: defs: let # Prepares the type definitions for mergeOptionDecls, which # annotates submodules types with file locations optionModules = map ({ value, file }: { _file = file; # There's no way to merge types directly from the module system, # but we can cheat a bit by just declaring an option with the type options = lib.mkOption { type = value; }; } ) defs; # Merges all the types into a single one, including submodule merging. # This also propagates file information to all submodules mergedOption = fixupOptionType loc (mergeOptionDecls loc optionModules); in mergedOption.type; }; </ins> submoduleWith = { modules , specialArgs ? {}
should only be used when checking, merging and nested evaluation are not desirable. <ins> `types.optionType` :   The type of an option's type. Its merging operation ensures that nested options have the correct file location annotated, and that if possible, multiple option definitions are correctly merged together. The main use case is as the type of the `_module.freeformType` option. </ins> `types.attrs` :   A free-form attribute set.
</varlistentry> <varlistentry> <term> <ins> <literal>types.optionType</literal> </term> <listitem> <para> The type of an option’s type. Its merging operation ensures that nested options have the correct file location annotated, and that if possible, multiple option definitions are correctly merged together. The main use case is as the type of the <literal>_module.freeformType</literal> option. </para> </listitem> </varlistentry> <varlistentry> <term> </ins> <literal>types.attrs</literal> </term> <listitem>