public
/
nixpkgs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

doc: Improve code listings 

By adding prompts and removing unnecessary indentation.
This commit is contained in:
Jan Tojnar 2020-09-23 00:38:04 +02:00
parent 47297487c5
commit e1af37634b
No known key found for this signature in database
GPG Key ID: 7FAB2A15F7A607A4
13 changed files with 173 additions and 161 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
doc/builders/images/dockertools.xml
View File

@ -132,11 +132,11 @@ buildImage {
<para> <para>
By default <function>buildImage</function> will use a static date of one second past the UNIX Epoch. This allows <function>buildImage</function> to produce binary reproducible images. When listing images with <command>docker images</command>, the newly created images will be listed like this: By default <function>buildImage</function> will use a static date of one second past the UNIX Epoch. This allows <function>buildImage</function> to produce binary reproducible images. When listing images with <command>docker images</command>, the newly created images will be listed like this:
</para> </para>
<screen><![CDATA[ <screen>
$ docker images <prompt>$ </prompt>docker images
REPOSITORY TAG IMAGE ID CREATED SIZE REPOSITORY TAG IMAGE ID CREATED SIZE
hello latest 08c791c7846e 48 years ago 25.2MB hello latest 08c791c7846e 48 years ago 25.2MB
]]></screen> </screen>
<para> <para>
You can break binary reproducibility but have a sorted, meaningful <literal>CREATED</literal> column by setting <literal>created</literal> to <literal>now</literal>. You can break binary reproducibility but have a sorted, meaningful <literal>CREATED</literal> column by setting <literal>created</literal> to <literal>now</literal>.
</para> </para>
@ -152,11 +152,11 @@ pkgs.dockerTools.buildImage {
]]></programlisting> ]]></programlisting>
<para> <para>
and now the Docker CLI will display a reasonable date and sort the images as expected: and now the Docker CLI will display a reasonable date and sort the images as expected:
<screen><![CDATA[ <screen>
$ docker images <prompt>$ </prompt>docker images
REPOSITORY TAG IMAGE ID CREATED SIZE REPOSITORY TAG IMAGE ID CREATED SIZE
hello latest de2bf4786de6 About a minute ago 25.2MB hello latest de2bf4786de6 About a minute ago 25.2MB
]]></screen> </screen>
however, the produced images will not be binary reproducible. however, the produced images will not be binary reproducible.
</para> </para>
</example> </example>

3
doc/builders/images/ocitools.xml
View File

@ -38,8 +38,7 @@ buildContainer {
readonly = false; <co xml:id='ex-ociTools-buildContainer-3' /> readonly = false; <co xml:id='ex-ociTools-buildContainer-3' />
} }
</programlisting>
</programlisting>
<calloutlist> <calloutlist>
<callout arearefs='ex-ociTools-buildContainer-1'> <callout arearefs='ex-ociTools-buildContainer-1'>
<para> <para>

8
doc/builders/packages/citrix.xml
View File

@ -22,10 +22,10 @@
</para> </para>
<para> <para>
In order to set this up, you first have to <link xlink:href="https://its.uiowa.edu/support/article/102186">download the <literal>.cr</literal> file from the Netscaler Gateway</link>. After that you can configure the <command>selfservice</command> like this: In order to set this up, you first have to <link xlink:href="https://its.uiowa.edu/support/article/102186">download the <literal>.cr</literal> file from the Netscaler Gateway</link>. After that you can configure the <command>selfservice</command> like this:
<screen> <screen>
<prompt>$ </prompt>storebrowse -C ~/Downloads/receiverconfig.cr <prompt>$ </prompt>storebrowse -C ~/Downloads/receiverconfig.cr
<prompt>$ </prompt>selfservice <prompt>$ </prompt>selfservice
</screen> </screen>
</para> </para>
</section> </section>

50
doc/builders/packages/urxvt.xml
View File

@ -18,10 +18,13 @@
includes all available plugins. To make use of this functionality, use an includes all available plugins. To make use of this functionality, use an
overlay or directly install an expression that overrides its configuration, overlay or directly install an expression that overrides its configuration,
such as such as
<programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: { <programlisting>
rxvt-unicode.override {
configure = { availablePlugins, ... }: {
plugins = with availablePlugins; [ perls resize-font vtwheel ]; plugins = with availablePlugins; [ perls resize-font vtwheel ];
} };
}</programlisting> }
</programlisting>
If the <literal>configure</literal> function returns an attrset without the If the <literal>configure</literal> function returns an attrset without the
<literal>plugins</literal> attribute, <literal>availablePlugins</literal> <literal>plugins</literal> attribute, <literal>availablePlugins</literal>
will be used automatically. will be used automatically.
@ -30,18 +33,22 @@
<para> <para>
In order to add plugins but also keep all default plugins installed, it is In order to add plugins but also keep all default plugins installed, it is
possible to use the following method: possible to use the following method:
<programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: { <programlisting>
plugins = (builtins.attrValues availablePlugins) ++ [ custom-plugin ]; rxvt-unicode.override {
}; configure = { availablePlugins, ... }: {
}</programlisting> plugins = (builtins.attrValues availablePlugins) ++ [ custom-plugin ];
};
}
</programlisting>
</para> </para>
<para> <para>
To get a list of all the plugins available, open the Nix REPL and run To get a list of all the plugins available, open the Nix REPL and run
<programlisting>$ nix repl <screen>
<prompt>$ </prompt>nix repl
:l &lt;nixpkgs&gt; :l &lt;nixpkgs&gt;
map (p: p.name) pkgs.rxvt-unicode.plugins map (p: p.name) pkgs.rxvt-unicode.plugins
</programlisting> </screen>
Alternatively, if your shell is bash or zsh and have completion enabled, Alternatively, if your shell is bash or zsh and have completion enabled,
simply type <literal>nixpkgs.rxvt-unicode.plugins.&lt;tab&gt;</literal>. simply type <literal>nixpkgs.rxvt-unicode.plugins.&lt;tab&gt;</literal>.
</para> </para>
@ -53,18 +60,24 @@ map (p: p.name) pkgs.rxvt-unicode.plugins
<literal>extraDeps</literal> can be used, for example, to provide <literal>extraDeps</literal> can be used, for example, to provide
<literal>xsel</literal> (a clipboard manager) to the clipboard plugin, <literal>xsel</literal> (a clipboard manager) to the clipboard plugin,
without installing it globally: without installing it globally:
<programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: { <programlisting>
pluginsDeps = [ xsel ]; rxvt-unicode.override {
} configure = { availablePlugins, ... }: {
}</programlisting> pluginsDeps = [ xsel ];
};
}
</programlisting>
<literal>perlDeps</literal> is a handy way to provide Perl packages to <literal>perlDeps</literal> is a handy way to provide Perl packages to
your custom plugins (in <literal>$HOME/.urxvt/ext</literal>). For example, your custom plugins (in <literal>$HOME/.urxvt/ext</literal>). For example,
if you need <literal>AnyEvent</literal> you can do: if you need <literal>AnyEvent</literal> you can do:
<programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: { <programlisting>
perlDeps = with perlPackages; [ AnyEvent ]; rxvt-unicode.override {
} configure = { availablePlugins, ... }: {
}</programlisting> perlDeps = with perlPackages; [ AnyEvent ];
};
}
</programlisting>
</para> </para>
</section> </section>
@ -90,7 +103,8 @@ map (p: p.name) pkgs.rxvt-unicode.plugins
<para> <para>
If the plugin is itself a perl package that needs to be imported from If the plugin is itself a perl package that needs to be imported from
other plugins or scripts, add the following passthrough: other plugins or scripts, add the following passthrough:
<programlisting>passthru.perlPackages = [ "self" ]; <programlisting>
passthru.perlPackages = [ "self" ];
</programlisting> </programlisting>
This will make the urxvt wrapper pick up the dependency and set up the perl This will make the urxvt wrapper pick up the dependency and set up the perl
path accordingly. path accordingly.

12
doc/contributing/submitting-changes.xml
View File

@ -209,12 +209,12 @@ Additional information.
</para> </para>
<programlisting> <programlisting>
(fetchpatch { (fetchpatch {
name = "CVE-2019-11068.patch"; name = "CVE-2019-11068.patch";
url = "https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6.patch"; url = "https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6.patch";
sha256 = "0pkpb4837km15zgg6h57bncp66d5lwrlvkr73h0lanywq7zrwhj8"; sha256 = "0pkpb4837km15zgg6h57bncp66d5lwrlvkr73h0lanywq7zrwhj8";
}) })
</programlisting> </programlisting>
<para> <para>
If a security fix applies to both master and a stable release then, similar to regular changes, they are preferably delivered via master first and cherry-picked to the release branch. If a security fix applies to both master and a stable release then, similar to regular changes, they are preferably delivered via master first and cherry-picked to the release branch.

6
doc/languages-frameworks/beam.xml
View File

@ -72,9 +72,9 @@
To install any of those builders into your profile, refer to them by their attribute path <literal>beamPackages.rebar3</literal>: To install any of those builders into your profile, refer to them by their attribute path <literal>beamPackages.rebar3</literal>:
</para> </para>
<screen> <screen>
<prompt>$ </prompt>nix-env -f &quot;&lt;nixpkgs&gt;&quot; -iA beamPackages.rebar3 <prompt>$ </prompt>nix-env -f &quot;&lt;nixpkgs&gt;&quot; -iA beamPackages.rebar3
</screen> </screen>
</section> </section>
<section xml:id="packaging-beam-applications"> <section xml:id="packaging-beam-applications">

186
doc/languages-frameworks/perl.xml
View File

@ -8,28 +8,28 @@
<para> <para>
When executing a Perl script, it is possible you get an error such as <literal>./myscript.pl: bad interpreter: /usr/bin/perl: no such file or directory</literal>. This happens when the script expects Perl to be installed at <filename>/usr/bin/perl</filename>, which is not the case when using Perl from nixpkgs. You can fix the script by changing the first line to: When executing a Perl script, it is possible you get an error such as <literal>./myscript.pl: bad interpreter: /usr/bin/perl: no such file or directory</literal>. This happens when the script expects Perl to be installed at <filename>/usr/bin/perl</filename>, which is not the case when using Perl from nixpkgs. You can fix the script by changing the first line to:
<programlisting> <programlisting>
#!/usr/bin/env perl #!/usr/bin/env perl
</programlisting> </programlisting>
to take the Perl installation from the <literal>PATH</literal> environment variable, or invoke Perl directly with: to take the Perl installation from the <literal>PATH</literal> environment variable, or invoke Perl directly with:
<screen> <screen>
<prompt>$ </prompt>perl ./myscript.pl <prompt>$ </prompt>perl ./myscript.pl
</screen> </screen>
</para> </para>
<para> <para>
When the script is using a Perl library that is not installed globally, you might get an error such as <literal>Can't locate DB_File.pm in @INC (you may need to install the DB_File module)</literal>. In that case, you can use <command>nix-shell</command> to start an ad-hoc shell with that library installed, for instance: When the script is using a Perl library that is not installed globally, you might get an error such as <literal>Can't locate DB_File.pm in @INC (you may need to install the DB_File module)</literal>. In that case, you can use <command>nix-shell</command> to start an ad-hoc shell with that library installed, for instance:
<screen> <screen>
<prompt>$ </prompt>nix-shell -p perl perlPackages.DBFile --run ./myscript.pl <prompt>$ </prompt>nix-shell -p perl perlPackages.DBFile --run ./myscript.pl
</screen> </screen>
</para> </para>
<para> <para>
If you are always using the script in places where <command>nix-shell</command> is available, you can embed the <command>nix-shell</command> invocation in the shebang like this: If you are always using the script in places where <command>nix-shell</command> is available, you can embed the <command>nix-shell</command> invocation in the shebang like this:
<programlisting> <programlisting>
#!/usr/bin/env nix-shell #!/usr/bin/env nix-shell
#! nix-shell -i perl -p perl perlPackages.DBFile #! nix-shell -i perl -p perl perlPackages.DBFile
</programlisting> </programlisting>
</para> </para>
</section> </section>
@ -44,30 +44,30 @@
<para> <para>
Perl packages from CPAN are defined in <link Perl packages from CPAN are defined in <link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix"><filename>pkgs/top-level/perl-packages.nix</filename></link>, rather than <filename>pkgs/all-packages.nix</filename>. Most Perl packages are so straight-forward to build that they are defined here directly, rather than having a separate function for each package called from <filename>perl-packages.nix</filename>. However, more complicated packages should be put in a separate file, typically in <filename>pkgs/development/perl-modules</filename>. Here is an example of the former: xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix"><filename>pkgs/top-level/perl-packages.nix</filename></link>, rather than <filename>pkgs/all-packages.nix</filename>. Most Perl packages are so straight-forward to build that they are defined here directly, rather than having a separate function for each package called from <filename>perl-packages.nix</filename>. However, more complicated packages should be put in a separate file, typically in <filename>pkgs/development/perl-modules</filename>. Here is an example of the former:
<programlisting> <programlisting>
ClassC3 = buildPerlPackage rec { ClassC3 = buildPerlPackage rec {
name = "Class-C3-0.21"; name = "Class-C3-0.21";
src = fetchurl { src = fetchurl {
url = "mirror://cpan/authors/id/F/FL/FLORA/${name}.tar.gz"; url = "mirror://cpan/authors/id/F/FL/FLORA/${name}.tar.gz";
sha256 = "1bl8z095y4js66pwxnm7s853pi9czala4sqc743fdlnk27kq94gz"; sha256 = "1bl8z095y4js66pwxnm7s853pi9czala4sqc743fdlnk27kq94gz";
}; };
}; };
</programlisting> </programlisting>
Note the use of <literal>mirror://cpan/</literal>, and the <literal>${name}</literal> in the URL definition to ensure that the name attribute is consistent with the source that we’re actually downloading. Perl packages are made available in <filename>all-packages.nix</filename> through the variable <varname>perlPackages</varname>. For instance, if you have a package that needs <varname>ClassC3</varname>, you would typically write Note the use of <literal>mirror://cpan/</literal>, and the <literal>${name}</literal> in the URL definition to ensure that the name attribute is consistent with the source that we’re actually downloading. Perl packages are made available in <filename>all-packages.nix</filename> through the variable <varname>perlPackages</varname>. For instance, if you have a package that needs <varname>ClassC3</varname>, you would typically write
<programlisting> <programlisting>
foo = import ../path/to/foo.nix { foo = import ../path/to/foo.nix {
inherit stdenv fetchurl ...; inherit stdenv fetchurl ...;
inherit (perlPackages) ClassC3; inherit (perlPackages) ClassC3;
}; };
</programlisting> </programlisting>
in <filename>all-packages.nix</filename>. You can test building a Perl package as follows: in <filename>all-packages.nix</filename>. You can test building a Perl package as follows:
<screen> <screen>
<prompt>$ </prompt>nix-build -A perlPackages.ClassC3 <prompt>$ </prompt>nix-build -A perlPackages.ClassC3
</screen> </screen>
<varname>buildPerlPackage</varname> adds <literal>perl-</literal> to the start of the name attribute, so the package above is actually called <literal>perl-Class-C3-0.21</literal>. So to install it, you can say: <varname>buildPerlPackage</varname> adds <literal>perl-</literal> to the start of the name attribute, so the package above is actually called <literal>perl-Class-C3-0.21</literal>. So to install it, you can say:
<screen> <screen>
<prompt>$ </prompt>nix-env -i perl-Class-C3 <prompt>$ </prompt>nix-env -i perl-Class-C3
</screen> </screen>
(Of course you can also install using the attribute name: <literal>nix-env -i -A perlPackages.ClassC3</literal>.) (Of course you can also install using the attribute name: <literal>nix-env -i -A perlPackages.ClassC3</literal>.)
</para> </para>
@ -94,61 +94,61 @@
<para> <para>
<varname>buildPerlPackage</varname> is built on top of <varname>stdenv</varname>, so everything can be customised in the usual way. For instance, the <literal>BerkeleyDB</literal> module has a <varname>preConfigure</varname> hook to generate a configuration file used by <filename>Makefile.PL</filename>: <varname>buildPerlPackage</varname> is built on top of <varname>stdenv</varname>, so everything can be customised in the usual way. For instance, the <literal>BerkeleyDB</literal> module has a <varname>preConfigure</varname> hook to generate a configuration file used by <filename>Makefile.PL</filename>:
<programlisting> <programlisting>
{ buildPerlPackage, fetchurl, db }: { buildPerlPackage, fetchurl, db }:
buildPerlPackage rec { buildPerlPackage rec {
name = "BerkeleyDB-0.36"; name = "BerkeleyDB-0.36";
src = fetchurl { src = fetchurl {
url = "mirror://cpan/authors/id/P/PM/PMQS/${name}.tar.gz"; url = "mirror://cpan/authors/id/P/PM/PMQS/${name}.tar.gz";
sha256 = "07xf50riarb60l1h6m2dqmql8q5dij619712fsgw7ach04d8g3z1"; sha256 = "07xf50riarb60l1h6m2dqmql8q5dij619712fsgw7ach04d8g3z1";
}; };
preConfigure = '' preConfigure = ''
echo "LIB = ${db.out}/lib" > config.in echo "LIB = ${db.out}/lib" > config.in
echo "INCLUDE = ${db.dev}/include" >> config.in echo "INCLUDE = ${db.dev}/include" >> config.in
''; '';
} }
</programlisting> </programlisting>
</para> </para>
<para> <para>
Dependencies on other Perl packages can be specified in the <varname>buildInputs</varname> and <varname>propagatedBuildInputs</varname> attributes. If something is exclusively a build-time dependency, use <varname>buildInputs</varname>; if it’s (also) a runtime dependency, use <varname>propagatedBuildInputs</varname>. For instance, this builds a Perl module that has runtime dependencies on a bunch of other modules: Dependencies on other Perl packages can be specified in the <varname>buildInputs</varname> and <varname>propagatedBuildInputs</varname> attributes. If something is exclusively a build-time dependency, use <varname>buildInputs</varname>; if it’s (also) a runtime dependency, use <varname>propagatedBuildInputs</varname>. For instance, this builds a Perl module that has runtime dependencies on a bunch of other modules:
<programlisting> <programlisting>
ClassC3Componentised = buildPerlPackage rec { ClassC3Componentised = buildPerlPackage rec {
name = "Class-C3-Componentised-1.0004"; name = "Class-C3-Componentised-1.0004";
src = fetchurl { src = fetchurl {
url = "mirror://cpan/authors/id/A/AS/ASH/${name}.tar.gz"; url = "mirror://cpan/authors/id/A/AS/ASH/${name}.tar.gz";
sha256 = "0xql73jkcdbq4q9m0b0rnca6nrlvf5hyzy8is0crdk65bynvs8q1"; sha256 = "0xql73jkcdbq4q9m0b0rnca6nrlvf5hyzy8is0crdk65bynvs8q1";
}; };
propagatedBuildInputs = [ propagatedBuildInputs = [
ClassC3 ClassInspector TestException MROCompat ClassC3 ClassInspector TestException MROCompat
]; ];
}; };
</programlisting> </programlisting>
</para> </para>
<para> <para>
On Darwin, if a script has too many <literal>-I<replaceable>dir</replaceable></literal> flags in its first line (its “shebang line”), it will not run. This can be worked around by calling the <literal>shortenPerlShebang</literal> function from the <literal>postInstall</literal> phase: On Darwin, if a script has too many <literal>-I<replaceable>dir</replaceable></literal> flags in its first line (its “shebang line”), it will not run. This can be worked around by calling the <literal>shortenPerlShebang</literal> function from the <literal>postInstall</literal> phase:
<programlisting> <programlisting>
{ stdenv, buildPerlPackage, fetchurl, shortenPerlShebang }: { stdenv, buildPerlPackage, fetchurl, shortenPerlShebang }:
ImageExifTool = buildPerlPackage { ImageExifTool = buildPerlPackage {
pname = "Image-ExifTool"; pname = "Image-ExifTool";
version = "11.50"; version = "11.50";
src = fetchurl { src = fetchurl {
url = "https://www.sno.phy.queensu.ca/~phil/exiftool/Image-ExifTool-11.50.tar.gz"; url = "https://www.sno.phy.queensu.ca/~phil/exiftool/Image-ExifTool-11.50.tar.gz";
sha256 = "0d8v48y94z8maxkmw1rv7v9m0jg2dc8xbp581njb6yhr7abwqdv3"; sha256 = "0d8v48y94z8maxkmw1rv7v9m0jg2dc8xbp581njb6yhr7abwqdv3";
}; };
buildInputs = stdenv.lib.optional stdenv.isDarwin shortenPerlShebang; buildInputs = stdenv.lib.optional stdenv.isDarwin shortenPerlShebang;
postInstall = stdenv.lib.optional stdenv.isDarwin '' postInstall = stdenv.lib.optional stdenv.isDarwin ''
shortenPerlShebang $out/bin/exiftool shortenPerlShebang $out/bin/exiftool
''; '';
}; };
</programlisting> </programlisting>
This will remove the <literal>-I</literal> flags from the shebang line, rewrite them in the <literal>use lib</literal> form, and put them on the next line instead. This function can be given any number of Perl scripts as arguments; it will modify them in-place. This will remove the <literal>-I</literal> flags from the shebang line, rewrite them in the <literal>use lib</literal> form, and put them on the next line instead. This function can be given any number of Perl scripts as arguments; it will modify them in-place.
</para> </para>
@ -159,27 +159,27 @@
Nix expressions for Perl packages can be generated (almost) automatically from CPAN. This is done by the program <command>nix-generate-from-cpan</command>, which can be installed as follows: Nix expressions for Perl packages can be generated (almost) automatically from CPAN. This is done by the program <command>nix-generate-from-cpan</command>, which can be installed as follows:
</para> </para>
<screen> <screen>
<prompt>$ </prompt>nix-env -i nix-generate-from-cpan <prompt>$ </prompt>nix-env -i nix-generate-from-cpan
</screen> </screen>
<para> <para>
This program takes a Perl module name, looks it up on CPAN, fetches and unpacks the corresponding package, and prints a Nix expression on standard output. For example: This program takes a Perl module name, looks it up on CPAN, fetches and unpacks the corresponding package, and prints a Nix expression on standard output. For example:
<screen> <screen>
<prompt>$ </prompt>nix-generate-from-cpan XML::Simple <prompt>$ </prompt>nix-generate-from-cpan XML::Simple
XMLSimple = buildPerlPackage rec { XMLSimple = buildPerlPackage rec {
name = "XML-Simple-2.22"; name = "XML-Simple-2.22";
src = fetchurl { src = fetchurl {
url = "mirror://cpan/authors/id/G/GR/GRANTM/${name}.tar.gz"; url = "mirror://cpan/authors/id/G/GR/GRANTM/${name}.tar.gz";
sha256 = "b9450ef22ea9644ae5d6ada086dc4300fa105be050a2030ebd4efd28c198eb49"; sha256 = "b9450ef22ea9644ae5d6ada086dc4300fa105be050a2030ebd4efd28c198eb49";
}; };
propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ]; propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ];
meta = { meta = {
description = "An API for simple XML files"; description = "An API for simple XML files";
license = with stdenv.lib.licenses; [ artistic1 gpl1Plus ]; license = with stdenv.lib.licenses; [ artistic1 gpl1Plus ];
}; };
}; };
</screen> </screen>
The output can be pasted into <filename>pkgs/top-level/perl-packages.nix</filename> or wherever else you need it. The output can be pasted into <filename>pkgs/top-level/perl-packages.nix</filename> or wherever else you need it.
</para> </para>
</section> </section>

2
doc/languages-frameworks/qt.xml
View File

@ -18,7 +18,7 @@ mkDerivation { <co xml:id='qt-default-nix-co-2' />
buildInputs = [ qtbase ]; <co xml:id='qt-default-nix-co-3' /> buildInputs = [ qtbase ]; <co xml:id='qt-default-nix-co-3' />
} }
</programlisting> </programlisting>
</example> </example>
<calloutlist> <calloutlist>

25
doc/languages-frameworks/ruby.xml
View File

@ -12,14 +12,14 @@
</para> </para>
<screen> <screen>
<![CDATA[$ cd pkgs/servers/monitoring <prompt>$ </prompt>cd pkgs/servers/monitoring
$ mkdir sensu <prompt>$ </prompt>mkdir sensu
$ cd sensu <prompt>$ </prompt>cd sensu
$ cat > Gemfile <prompt>$ </prompt>cat > Gemfile
source 'https://rubygems.org' source 'https://rubygems.org'
gem 'sensu' gem 'sensu'
$ $(nix-build '<nixpkgs>' -A bundix --no-out-link)/bin/bundix --magic <prompt>$ </prompt>$(nix-build '&lt;nixpkgs>' -A bundix --no-out-link)/bin/bundix --magic
$ cat > default.nix <prompt>$ </prompt>cat > default.nix
{ lib, bundlerEnv, ruby }: { lib, bundlerEnv, ruby }:
bundlerEnv rec { bundlerEnv rec {
@ -37,7 +37,7 @@ bundlerEnv rec {
maintainers = with maintainers; [ theuni ]; maintainers = with maintainers; [ theuni ];
platforms = platforms.unix; platforms = platforms.unix;
}; };
}]]> }
</screen> </screen>
<para> <para>
@ -49,17 +49,16 @@ bundlerEnv rec {
</para> </para>
<screen> <screen>
<![CDATA[$ cd pkgs/servers/monitoring/sensu <prompt>$ </prompt>cd pkgs/servers/monitoring/sensu
$ nix-shell -p bundler --run 'bundle lock --update' <prompt>$ </prompt>nix-shell -p bundler --run 'bundle lock --update'
$ nix-shell -p bundix --run 'bundix' <prompt>$ </prompt>nix-shell -p bundix --run 'bundix'
]]>
</screen> </screen>
<para> <para>
For tools written in Ruby - i.e. where the desire is to install a package and then execute e.g. <command>rake</command> at the command line, there is an alternative builder called <literal>bundlerApp</literal>. Set up the <filename>gemset.nix</filename> the same way, and then, for example: For tools written in Ruby - i.e. where the desire is to install a package and then execute e.g. <command>rake</command> at the command line, there is an alternative builder called <literal>bundlerApp</literal>. Set up the <filename>gemset.nix</filename> the same way, and then, for example:
</para> </para>
<screen> <programlisting>
<![CDATA[{ lib, bundlerApp }: <![CDATA[{ lib, bundlerApp }:
bundlerApp { bundlerApp {
@ -75,7 +74,7 @@ bundlerApp {
platforms = platforms.unix; platforms = platforms.unix;
}; };
}]]> }]]>
</screen> </programlisting>
<para> <para>
The chief advantage of <literal>bundlerApp</literal> over <literal>bundlerEnv</literal> is the executables introduced in the environment are precisely those selected in the <literal>exes</literal> list, as opposed to <literal>bundlerEnv</literal> which adds all the executables made available by gems in the gemset, which can mean e.g. <command>rspec</command> or <command>rake</command> in unpredictable versions available from various packages. The chief advantage of <literal>bundlerApp</literal> over <literal>bundlerEnv</literal> is the executables introduced in the environment are precisely those selected in the <literal>exes</literal> list, as opposed to <literal>bundlerEnv</literal> which adds all the executables made available by gems in the gemset, which can mean e.g. <command>rspec</command> or <command>rake</command> in unpredictable versions available from various packages.

10
doc/languages-frameworks/texlive.xml
View File

@ -44,11 +44,11 @@ texlive.combine {
<listitem> <listitem>
<para> <para>
You can list packages e.g. by <command>nix repl</command>. You can list packages e.g. by <command>nix repl</command>.
<programlisting><![CDATA[ <programlisting>
$ nix repl <prompt>$ </prompt>nix repl
nix-repl> :l <nixpkgs> <prompt>nix-repl> </prompt>:l &lt;nixpkgs>
nix-repl> texlive.collection-<TAB> <prompt>nix-repl> </prompt>texlive.collection-<keycap function="tab" />
]]></programlisting> </programlisting>
</para> </para>
</listitem> </listitem>
<listitem> <listitem>

2
doc/stdenv/multiple-output.xml
View File

@ -67,7 +67,7 @@
<para> <para>
<command>nix-env</command> silenty disregards the outputs selected by the user, and instead installs the outputs from <varname>meta.outputsToInstall</varname>. For example, <command>nix-env</command> silenty disregards the outputs selected by the user, and instead installs the outputs from <varname>meta.outputsToInstall</varname>. For example,
</para> </para>
<programlisting>$ nix-env -iA nixpkgs.coreutils.info</programlisting> <screen><prompt>$ </prompt>nix-env -iA nixpkgs.coreutils.info</screen>
<para> <para>
installs the <literal>"out"</literal> output (<varname>coreutils.meta.outputsToInstall</varname> is <literal>[ "out" ]</literal>) instead of the requested <literal>"info"</literal>. installs the <literal>"out"</literal> output (<varname>coreutils.meta.outputsToInstall</varname> is <literal>[ "out" ]</literal>) instead of the requested <literal>"info"</literal>.
</para> </para>

8
doc/using/configuration.xml
View File

@ -66,7 +66,7 @@
<listitem> <listitem>
<para> <para>
For allowing the build of a broken package once, you can use an environment variable for a single invocation of the nix tools: For allowing the build of a broken package once, you can use an environment variable for a single invocation of the nix tools:
<programlisting>$ export NIXPKGS_ALLOW_BROKEN=1</programlisting> <screen><prompt>$ </prompt>export NIXPKGS_ALLOW_BROKEN=1</screen>
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
@ -92,7 +92,7 @@
<listitem> <listitem>
<para> <para>
For allowing the build of an unsupported package once, you can use an environment variable for a single invocation of the nix tools: For allowing the build of an unsupported package once, you can use an environment variable for a single invocation of the nix tools:
<programlisting>$ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1</programlisting> <screen><prompt>$ </prompt>export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1</screen>
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
@ -122,7 +122,7 @@
<listitem> <listitem>
<para> <para>
To temporarily allow all unfree packages, you can use an environment variable for a single invocation of the nix tools: To temporarily allow all unfree packages, you can use an environment variable for a single invocation of the nix tools:
<programlisting>$ export NIXPKGS_ALLOW_UNFREE=1</programlisting> <screen><prompt>$ </prompt>export NIXPKGS_ALLOW_UNFREE=1</screen>
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
@ -187,7 +187,7 @@
<listitem> <listitem>
<para> <para>
To temporarily allow all insecure packages, you can use an environment variable for a single invocation of the nix tools: To temporarily allow all insecure packages, you can use an environment variable for a single invocation of the nix tools:
<programlisting>$ export NIXPKGS_ALLOW_INSECURE=1</programlisting> <screen><prompt>$ </prompt>export NIXPKGS_ALLOW_INSECURE=1</screen>
</para> </para>
</listitem> </listitem>
<listitem> <listitem>

10
doc/using/overlays.xml
View File

@ -240,7 +240,7 @@ self: super:
lapackProvider = self.mkl; lapackProvider = self.mkl;
} }
} }
</programlisting> </programlisting>
<para> <para>
This overlay uses Intel’s MKL library for both BLAS and LAPACK This overlay uses Intel’s MKL library for both BLAS and LAPACK
interfaces. Note that the same can be accomplished at runtime interfaces. Note that the same can be accomplished at runtime
@ -248,9 +248,9 @@ self: super:
<literal>libblas.so.3</literal> and <literal>libblas.so.3</literal> and
<literal>liblapack.so.3</literal>. For instance: <literal>liblapack.so.3</literal>. For instance:
</para> </para>
<programlisting> <screen>
$ LD_LIBRARY_PATH=$(nix-build -A mkl)/lib:$LD_LIBRARY_PATH nix-shell -p octave --run octave <prompt>$ </prompt>LD_LIBRARY_PATH=$(nix-build -A mkl)/lib:$LD_LIBRARY_PATH nix-shell -p octave --run octave
</programlisting> </screen>
<para> <para>
Intel MKL requires an <literal>openmp</literal> implementation Intel MKL requires an <literal>openmp</literal> implementation
when running with multiple processors. By default, when running with multiple processors. By default,
@ -288,7 +288,7 @@ assert (!blas.isILP64) &amp;&amp; (!lapack.isILP64);
stdenv.mkDerivation { stdenv.mkDerivation {
... ...
} }
</programlisting> </programlisting>
</section> </section>
</section> </section>
</chapter> </chapter>