Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

lib/customisation.nix: add addToPassthru #77466

Closed
wants to merge 4 commits into from
Closed

lib/customisation.nix: add addToPassthru #77466

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
65b0cca
doc: add lib/customisation.nix to auto-generated docs
Profpatsch Jan 10, 2020
ef67da8
lib/customisation.nix: add addToPassthru
Profpatsch Jan 10, 2020
010efbd
doc: apply automatic linter fixup
Profpatsch Jan 10, 2020
c2c491a
lib/tests: add test for addToPassthru
Profpatsch Jan 10, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
3 changes: 1 addition & 2 deletions doc/builders/fetchers.xml
View file
Open in desktop
Expand Up @@ -111,8 +111,7 @@ stdenv.mkDerivation {
</term>
<listitem>
<para>
This is used with Gitiles repositories. The arguments expected
are similar to fetchgit.
This is used with Gitiles repositories. The arguments expected are similar to fetchgit.
</para>
</listitem>
</varlistentry>
Expand Down
6 changes: 4 additions & 2 deletions doc/builders/trivial-builders.xml
View file
Open in desktop
Expand Up @@ -58,9 +58,11 @@
<para>
Variant of <literal>runCommand</literal> that forces the derivation to be built locally, it is not substituted. This is intended for very cheap commands (&lt;1s execution time). It saves on the network roundrip and can speed up a build.
</para>
<note><para>
<note>
<para>
This sets <link xlink:href="https://nixos.org/nix/manual/#adv-attr-allowSubstitutes"><literal>allowSubstitutes</literal> to <literal>false</literal></link>, so only use <literal>runCommandLocal</literal> if you are certain the user will always have a builder for the <literal>system</literal> of the derivation. This should be true for most trivial use cases (e.g. just copying some files to a different location or adding symlinks), because there the <literal>system</literal> is usually the same as <literal>builtins.currentSystem</literal>.
</para></note>
</para>
</note>
</listitem>
</varlistentry>
<varlistentry xml:id="trivial-builder-writeText">
Expand Down
3 changes: 1 addition & 2 deletions doc/contributing/coding-conventions.xml
View file
Open in desktop
Expand Up @@ -664,8 +664,7 @@ args.stdenv.mkDerivation (args // {
</varlistentry>
<varlistentry>
<term>
If it’s a <emphasis>theme</emphasis> for a <emphasis>desktop environment</emphasis>,
a <emphasis>window manager</emphasis> or a <emphasis>display manager</emphasis>:
If it’s a <emphasis>theme</emphasis> for a <emphasis>desktop environment</emphasis>, a <emphasis>window manager</emphasis> or a <emphasis>display manager</emphasis>:
</term>
<listitem>
<para>
Expand Down
22 changes: 10 additions & 12 deletions doc/contributing/submitting-changes.xml
View file
Open in desktop
Expand Up @@ -294,17 +294,17 @@ Additional information.

<para>
review changes from pull request number 12345:
<screen>nix run nixpkgs.nixpkgs-review -c nixpkgs-review pr 12345</screen>
<screen>nix run nixpkgs.nixpkgs-review -c nixpkgs-review pr 12345</screen>
</para>

<para>
review uncommitted changes:
<screen>nix run nixpkgs.nixpkgs-review -c nixpkgs-review wip</screen>
<screen>nix run nixpkgs.nixpkgs-review -c nixpkgs-review wip</screen>
</para>

<para>
review changes from last commit:
<screen>nix run nixpkgs.nixpkgs-review -c nixpkgs-review rev HEAD</screen>
<screen>nix run nixpkgs.nixpkgs-review -c nixpkgs-review rev HEAD</screen>
</para>
</section>

Expand Down Expand Up @@ -376,29 +376,27 @@ Additional information.

<section xml:id="submitting-changes-master-branch">
<title>Master branch</title>

<para>
The <literal>master</literal> branch is the main development branch.
It should only see non-breaking commits that do not cause mass rebuilds.
The <literal>master</literal> branch is the main development branch. It should only see non-breaking commits that do not cause mass rebuilds.
</para>
</section>

<section xml:id="submitting-changes-staging-branch">
<title>Staging branch</title>

<para>
The <literal>staging</literal> branch is a development branch where mass-rebuilds go.
It should only see non-breaking mass-rebuild commits.
That means it is not to be used for testing, and changes must have been well tested already.
If the branch is already in a broken state, please refrain from adding extra new breakages.
The <literal>staging</literal> branch is a development branch where mass-rebuilds go. It should only see non-breaking mass-rebuild commits. That means it is not to be used for testing, and changes must have been well tested already. If the branch is already in a broken state, please refrain from adding extra new breakages.
</para>
</section>

<section xml:id="submitting-changes-staging-next-branch">
<title>Staging-next branch</title>

<para>
The <literal>staging-next</literal> branch is for stabilizing mass-rebuilds submitted to the <literal>staging</literal> branch prior to merging them into <literal>master</literal>.
Mass-rebuilds should go via the <literal>staging</literal> branch.
It should only see non-breaking commits that are fixing issues blocking it from being merged into the <literal>master </literal> branch.
The <literal>staging-next</literal> branch is for stabilizing mass-rebuilds submitted to the <literal>staging</literal> branch prior to merging them into <literal>master</literal>. Mass-rebuilds should go via the <literal>staging</literal> branch. It should only see non-breaking commits that are fixing issues blocking it from being merged into the <literal>master </literal> branch.
</para>

<para>
If the branch is already in a broken state, please refrain from adding extra new breakages. Stabilize it for a few days and then merge into master.
</para>
Expand Down
3 changes: 2 additions & 1 deletion doc/doc-support/lib-function-docs.nix
View file
Open in desktop
@@ -1,6 +1,6 @@
# Generates the documentation for library functons via nixdoc. To add
# another library function file to this list, the include list in the
# file `doc/functions/library.xml` must also be updated.
# file `../functions/library.xml` must also be updated.

{ pkgs ? import ./.. {}, locationsXml }:

Expand All @@ -21,6 +21,7 @@ with pkgs; stdenv.mkDerivation {
docgen trivial 'Miscellaneous functions'
docgen lists 'List manipulation functions'
docgen debug 'Debugging functions'
docgen customisation 'Manipulation of derivation functions'
docgen options 'NixOS / nixpkgs option handling'
'';
}
4 changes: 3 additions & 1 deletion doc/functions/library.xml
View file
Open in desktop
Expand Up @@ -14,7 +14,7 @@

<!-- These docs are generated via nixdoc. To add another generated
library function file to this list, the file
`lib-function-docs.nix` must also be updated. -->
`../doc-support/lib-function-docs.nix` must also be updated. -->

<xi:include href="./library/generated/strings.xml" />

Expand All @@ -24,5 +24,7 @@

<xi:include href="./library/generated/debug.xml" />

<xi:include href="./library/generated/customisation.xml" />

<xi:include href="./library/generated/options.xml" />
</section>
15 changes: 6 additions & 9 deletions doc/languages-frameworks/beam.xml
View file
Open in desktop
Expand Up @@ -68,14 +68,13 @@
<title>How to Install BEAM Packages</title>

<para>
BEAM builders are not registered at the top level, simply because they are not relevant to the vast majority of Nix users.
To install any of those builders into your profile, refer to them by their attribute path <literal>beamPackages.rebar3</literal>:
BEAM builders are not registered at the top level, simply because they are not relevant to the vast majority of Nix users. To install any of those builders into your profile, refer to them by their attribute path <literal>beamPackages.rebar3</literal>:
</para>

<screen>
<screen>
<prompt>$ </prompt>nix-env -f &quot;&lt;nixpkgs&gt;&quot; -iA beamPackages.rebar3
</screen>
</section>
</section>

<section xml:id="packaging-beam-applications">
<title>Packaging BEAM Applications</title>
Expand All @@ -101,7 +100,6 @@
<para>
Erlang.mk functions similarly to Rebar3, except we use <literal>buildErlangMk</literal> instead of <literal>buildRebar3</literal>.
</para>

</section>

<section xml:id="mix-packages">
Expand All @@ -124,10 +122,9 @@
<section xml:id="creating-a-shell">
<title>Creating a Shell</title>

<para>
Usually, we need to create a <literal>shell.nix</literal> file and do our development inside of the environment specified therein. Just install your version of erlang and other interpreter, and then user your normal build tools.
As an example with elixir:
</para>
<para>
Usually, we need to create a <literal>shell.nix</literal> file and do our development inside of the environment specified therein. Just install your version of erlang and other interpreter, and then user your normal build tools. As an example with elixir:
</para>

<programlisting>
{ pkgs ? import &quot;&lt;nixpkgs&quot;&gt; {} }:
Expand Down
3 changes: 2 additions & 1 deletion doc/languages-frameworks/texlive.xml
View file
Open in desktop
Expand Up @@ -61,8 +61,9 @@ nix-repl> texlive.collection-<TAB>

<section xml:id="sec-language-texlive-custom-packages">
<title>Custom packages</title>

<para>
You may find that you need to use an external TeX package. A derivation for such package has to provide contents of the "texmf" directory in its output and provide the <varname>tlType</varname> attribute. Here is a (very verbose) example:
You may find that you need to use an external TeX package. A derivation for such package has to provide contents of the "texmf" directory in its output and provide the <varname>tlType</varname> attribute. Here is a (very verbose) example:
<programlisting><![CDATA[
with import <nixpkgs> {};

Expand Down
4 changes: 2 additions & 2 deletions doc/stdenv/stdenv.xml
View file
Open in desktop
Expand Up @@ -1123,9 +1123,9 @@ preBuild = ''

<variablelist>
<title>Variables controlling the install phase</title>
<varlistentry>
<varlistentry>
<term>
<varname>dontInstall</varname>
<varname>dontInstall</varname>
</term>
<listitem>
<para>
Expand Down
21 changes: 21 additions & 0 deletions lib/customisation.nix
View file
Open in desktop
Expand Up @@ -159,6 +159,27 @@ rec {
outPath = assert condition; drv.outPath;
};

/* Add a field to a derivation’s passthru. Will refuse to add a field that is already there.

Type: { name: string, value: any } -> drv -> drv

Example:
(addToPassthru
{ name = "foo"; value = "bar"; }
pkgs.hello).passthru.foo
=> "bar"
*/
addToPassthru =
# field to add
{name, value}:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we end up having this function I think it's much better to pass the attribute set directly as passthru's, instead of using name and value. This is more natural, allows automatic support for multiple passthru's, is more concise, and more efficient too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean to add multiple fields at once?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, just addToPassthru = passthrus: ... { passthru = old.passthru or {} // passthrus; }

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So add multiple fields at once?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess yeah :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well it doesn't have to be used for multiple fields of course

# derivation to add field to
drv:
assert (lib.assertMsg (!drv ? ${name})
"${lib.generators.toPretty {} drv} already has attribute `${name}`, refusing to add to passthru");
drv.overrideAttrs (old: {
passthru = old.passthru or {} // { ${name} = value; };
});

/* Strip a derivation of all non-essential attributes, returning
only those needed by hydra-eval-jobs. Also strictly evaluate the
result to ensure that there are no thunks kept alive to prevent
Expand Down
4 changes: 2 additions & 2 deletions lib/default.nix
View file
Open in desktop
Expand Up @@ -93,8 +93,8 @@ let
inherit (stringsWithDeps) textClosureList textClosureMap
noDepEntry fullDepEntry packEntry stringAfter;
inherit (customisation) overrideDerivation makeOverridable
callPackageWith callPackagesWith extendDerivation hydraJob
makeScope;
callPackageWith callPackagesWith extendDerivation addToPassthru
hydraJob makeScope;
inherit (meta) addMetaAttrs dontDistribute setName updateName
appendToName mapDerivationAttrset setPrio lowPrio lowPrioSet hiPrio
hiPrioSet;
Expand Down
29 changes: 28 additions & 1 deletion lib/tests/misc.nix
View file
Open in desktop
Expand Up @@ -441,7 +441,10 @@ runTests {
expected = "«foo»";
};

testRenderOptions = {

# CLI

testEncodeGNUCommandLine = {
expr =
encodeGNUCommandLine
{ }
Expand All @@ -462,4 +465,28 @@ runTests {

expected = "'-X' 'PUT' '--data' '{\"id\":0}' '--retry' '3' '--url' 'https://example.com/foo' '--url' 'https://example.com/bar' '--verbose'";
};


# CUSTOMISATION

testAddToPassthru = {
expr =
let
attrs = {
name = "abc";
passthru = { x = 41; };
};
drv = attrs // { overrideAttrs = f: attrs // f attrs; };
in addToPassthru
{ name = "foo"; value = "bar"; }
drv;
expected = {
name = "abc";
passthru = {
x = 41;
foo = "bar";
};
};
};

}