Merge pull request #116257 from SuperSandro2000/code-fences
doc/languages-frameworks/*: add missing languages to code fences
This commit is contained in:
Sandro
GitHub
commit
3a6116c550
7 changed files with 57 additions and 56 deletions
|
|
@ -3,7 +3,7 @@
|
|||
## How to use Agda
|
||||
|
||||
Agda can be installed from `agda`:
|
||||
```
|
||||
```ShellSession
|
||||
$ nix-env -iA agda
|
||||
```
|
||||
|
||||
|
|
@ -15,13 +15,13 @@ To use Agda with libraries, the `agda.withPackages` function can be used. This f
|
|||
|
||||
For example, suppose we wanted a version of Agda which has access to the standard library. This can be obtained with the expressions:
|
||||
|
||||
```
|
||||
```nix
|
||||
agda.withPackages [ agdaPackages.standard-library ]
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```
|
||||
```nix
|
||||
agda.withPackages (p: [ p.standard-library ])
|
||||
```
|
||||
|
||||
|
|
@ -32,7 +32,7 @@ If you want to use a library in your home directory (for instance if it is a dev
|
|||
Agda will not by default use these libraries. To tell Agda to use the library we have some options:
|
||||
|
||||
* Call `agda` with the library flag:
|
||||
```
|
||||
```ShellSession
|
||||
$ agda -l standard-library -i . MyFile.agda
|
||||
```
|
||||
* Write a `my-library.agda-lib` file for the project you are working on which may look like:
|
||||
|
|
@ -49,7 +49,7 @@ More information can be found in the [official Agda documentation on library man
|
|||
Agda modules can be compiled with the `--compile` flag. A version of `ghc` with `ieee754` is made available to the Agda program via the `--with-compiler` flag.
|
||||
This can be overridden by a different version of `ghc` as follows:
|
||||
|
||||
```
|
||||
```nix
|
||||
agda.withPackages {
|
||||
pkgs = [ ... ];
|
||||
ghc = haskell.compiler.ghcHEAD;
|
||||
|
|
@ -80,12 +80,12 @@ By default, Agda sources are files ending on `.agda`, or literate Agda files end
|
|||
## Adding Agda packages to Nixpkgs
|
||||
|
||||
To add an Agda package to `nixpkgs`, the derivation should be written to `pkgs/development/libraries/agda/${library-name}/` and an entry should be added to `pkgs/top-level/agda-packages.nix`. Here it is called in a scope with access to all other Agda libraries, so the top line of the `default.nix` can look like:
|
||||
```
|
||||
```nix
|
||||
{ mkDerivation, standard-library, fetchFromGitHub }:
|
||||
```
|
||||
and `mkDerivation` should be called instead of `agdaPackages.mkDerivation`. Here is an example skeleton derivation for iowa-stdlib:
|
||||
|
||||
```
|
||||
```nix
|
||||
mkDerivation {
|
||||
version = "1.5.0";
|
||||
pname = "iowa-stdlib";
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
For local development, it's recommended to use nix-shell to create a dotnet environment:
|
||||
|
||||
```
|
||||
```nix
|
||||
# shell.nix
|
||||
with import <nixpkgs> {};
|
||||
|
||||
|
|
@ -20,7 +20,7 @@ mkShell {
|
|||
|
||||
It's very likely that more than one sdk will be needed on a given project. Dotnet provides several different frameworks (E.g dotnetcore, aspnetcore, etc.) as well as many versions for a given framework. Normally, dotnet is able to fetch a framework and install it relative to the executable. However, this would mean writing to the nix store in nixpkgs, which is read-only. To support the many-sdk use case, one can compose an environment using `dotnetCorePackages.combinePackages`:
|
||||
|
||||
```
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
|
||||
mkShell {
|
||||
|
|
@ -37,7 +37,7 @@ mkShell {
|
|||
|
||||
This will produce a dotnet installation that has the dotnet 3.1, 3.0, and 2.1 sdk. The first sdk listed will have it's cli utility present in the resulting environment. Example info output:
|
||||
|
||||
```
|
||||
```ShellSesssion
|
||||
$ dotnet --info
|
||||
.NET Core SDK (reflecting any global.json):
|
||||
Version: 3.1.101
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
The easiest way to get a working idris version is to install the `idris` attribute:
|
||||
|
||||
```
|
||||
```ShellSesssion
|
||||
$ # On NixOS
|
||||
$ nix-env -i nixos.idris
|
||||
$ # On non-NixOS
|
||||
|
|
@ -21,7 +21,7 @@ self: super: {
|
|||
|
||||
And then:
|
||||
|
||||
```
|
||||
```ShellSesssion
|
||||
$ # On NixOS
|
||||
$ nix-env -iA nixos.myIdris
|
||||
$ # On non-NixOS
|
||||
|
|
@ -29,7 +29,7 @@ $ nix-env -iA nixpkgs.myIdris
|
|||
```
|
||||
|
||||
To see all available Idris packages:
|
||||
```
|
||||
```ShellSesssion
|
||||
$ # On NixOS
|
||||
$ nix-env -qaPA nixos.idrisPackages
|
||||
$ # On non-NixOS
|
||||
|
|
@ -37,7 +37,7 @@ $ nix-env -qaPA nixpkgs.idrisPackages
|
|||
```
|
||||
|
||||
Similarly, entering a `nix-shell`:
|
||||
```
|
||||
```ShellSesssion
|
||||
$ nix-shell -p 'idrisPackages.with-packages (with idrisPackages; [ contrib pruviloj ])'
|
||||
```
|
||||
|
||||
|
|
@ -45,14 +45,14 @@ $ nix-shell -p 'idrisPackages.with-packages (with idrisPackages; [ contrib pruvi
|
|||
|
||||
To have access to these libraries in idris, call it with an argument `-p <library name>` for each library:
|
||||
|
||||
```
|
||||
```ShellSesssion
|
||||
$ nix-shell -p 'idrisPackages.with-packages (with idrisPackages; [ contrib pruviloj ])'
|
||||
[nix-shell:~]$ idris -p contrib -p pruviloj
|
||||
```
|
||||
|
||||
A listing of all available packages the Idris binary has access to is available via `--listlibs`:
|
||||
|
||||
```
|
||||
```ShellSesssion
|
||||
$ idris --listlibs
|
||||
00prelude-idx.ibc
|
||||
pruviloj
|
||||
|
|
@ -105,7 +105,7 @@ build-idris-package {
|
|||
|
||||
Assuming this file is saved as `yaml.nix`, it's buildable using
|
||||
|
||||
```
|
||||
```ShellSesssion
|
||||
$ nix-build -E '(import <nixpkgs> {}).idrisPackages.callPackage ./yaml.nix {}'
|
||||
```
|
||||
|
||||
|
|
@ -121,7 +121,7 @@ with import <nixpkgs> {};
|
|||
|
||||
in another file (say `default.nix`) to be able to build it with
|
||||
|
||||
```
|
||||
```ShellSesssion
|
||||
$ nix-build -A yaml
|
||||
```
|
||||
|
||||
|
|
@ -133,7 +133,7 @@ Specifically, you can set `idrisBuildOptions`, `idrisTestOptions`, `idrisInstall
|
|||
|
||||
For example you could set
|
||||
|
||||
```
|
||||
```nix
|
||||
build-idris-package {
|
||||
idrisBuildOptions = [ "--log" "1" "--verbose" ]
|
||||
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ $ nix-shell -p 'python38.withPackages(ps: with ps; [ numpy toolz ])'
|
|||
By default `nix-shell` will start a `bash` session with this interpreter in our
|
||||
`PATH`, so if we then run:
|
||||
|
||||
```
|
||||
```Python console
|
||||
[nix-shell:~/src/nixpkgs]$ python3
|
||||
Python 3.8.1 (default, Dec 18 2019, 19:06:26)
|
||||
[GCC 9.2.0] on linux
|
||||
|
|
@ -90,7 +90,7 @@ Type "help", "copyright", "credits" or "license" for more information.
|
|||
Note that no other modules are in scope, even if they were imperatively
|
||||
installed into our user environment as a dependency of a Python application:
|
||||
|
||||
```
|
||||
```Python console
|
||||
>>> import requests
|
||||
Traceback (most recent call last):
|
||||
File "<stdin>", line 1, in <module>
|
||||
|
|
@ -146,8 +146,8 @@ print(f"The dot product of {a} and {b} is: {np.dot(a, b)}")
|
|||
Executing this script requires a `python3` that has `numpy`. Using what we learned
|
||||
in the previous section, we could startup a shell and just run it like so:
|
||||
|
||||
```
|
||||
nix-shell -p 'python38.withPackages(ps: with ps; [ numpy ])' --run 'python3 foo.py'
|
||||
```ShellSesssion
|
||||
$ nix-shell -p 'python38.withPackages(ps: with ps; [ numpy ])' --run 'python3 foo.py'
|
||||
The dot product of [1 2] and [3 4] is: 11
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ supported Qt version.
|
|||
### Example adding a Qt library {#qt-library-all-packages-nix}
|
||||
|
||||
The following represents the contents of `qt5-packages.nix`.
|
||||
```
|
||||
```nix
|
||||
{
|
||||
# ...
|
||||
|
||||
|
|
@ -133,7 +133,7 @@ to select the Qt 5 version used for the application.
|
|||
### Example adding a Qt application {#qt-application-all-packages-nix}
|
||||
|
||||
The following represents the contents of `qt5-packages.nix`.
|
||||
```
|
||||
```nix
|
||||
{
|
||||
# ...
|
||||
|
||||
|
|
@ -144,7 +144,7 @@ The following represents the contents of `qt5-packages.nix`.
|
|||
```
|
||||
|
||||
The following represents the contents of `all-packages.nix`.
|
||||
```
|
||||
```nix
|
||||
{
|
||||
# ...
|
||||
|
||||
|
|
|
|||
|
|
@ -2,13 +2,14 @@
|
|||
|
||||
To install the rust compiler and cargo put
|
||||
|
||||
```
|
||||
rustc
|
||||
cargo
|
||||
```nix
|
||||
environment.systemPackages = [
|
||||
rustc
|
||||
cargo
|
||||
];
|
||||
```
|
||||
|
||||
into the `environment.systemPackages` or bring them into
|
||||
scope with `nix-shell -p rustc cargo`.
|
||||
into your `configuration.nix` or bring them into scope with `nix-shell -p rustc cargo`.
|
||||
|
||||
For other versions such as daily builds (beta and nightly),
|
||||
use either `rustup` from nixpkgs (which will manage the rust installation in your home directory),
|
||||
|
|
@ -18,7 +19,7 @@ or use Mozilla's [Rust nightlies overlay](#using-the-rust-nightlies-overlay).
|
|||
|
||||
Rust applications are packaged by using the `buildRustPackage` helper from `rustPlatform`:
|
||||
|
||||
```
|
||||
```nix
|
||||
{ lib, rustPlatform }:
|
||||
|
||||
rustPlatform.buildRustPackage rec {
|
||||
|
|
@ -49,7 +50,7 @@ package. `cargoHash256` is used for traditional Nix SHA-256 hashes,
|
|||
such as the one in the example above. `cargoHash` should instead be
|
||||
used for [SRI](https://www.w3.org/TR/SRI/) hashes. For example:
|
||||
|
||||
```
|
||||
```nix
|
||||
cargoHash = "sha256-l1vL2ZdtDRxSGvP0X/l3nMw8+6WF67KPutJEzUROjg8=";
|
||||
```
|
||||
|
||||
|
|
@ -59,13 +60,13 @@ expression and building the package once. The correct checksum can
|
|||
then be taken from the failed build. A fake hash can be used for
|
||||
`cargoSha256` as follows:
|
||||
|
||||
```
|
||||
```nix
|
||||
cargoSha256 = lib.fakeSha256;
|
||||
```
|
||||
|
||||
For `cargoHash` you can use:
|
||||
|
||||
```
|
||||
```nix
|
||||
cargoHash = lib.fakeHash;
|
||||
```
|
||||
|
||||
|
|
@ -262,7 +263,7 @@ Otherwise, some steps may fail because of the modified directory structure of `t
|
|||
source code in a reproducible way. If it is missing or out-of-date one can use
|
||||
the `cargoPatches` attribute to update or add it.
|
||||
|
||||
```
|
||||
```nix
|
||||
rustPlatform.buildRustPackage rec {
|
||||
(...)
|
||||
cargoPatches = [
|
||||
|
|
@ -489,7 +490,7 @@ an example for a minimal `hello` crate:
|
|||
|
||||
Now, the file produced by the call to `carnix`, called `hello.nix`, looks like:
|
||||
|
||||
```
|
||||
```nix
|
||||
# Generated by carnix 0.6.5: carnix -o hello.nix --src ./. Cargo.lock --standalone
|
||||
{ stdenv, buildRustCrate, fetchgit }:
|
||||
let kernel = stdenv.buildPlatform.parsed.kernel.name;
|
||||
|
|
@ -518,7 +519,7 @@ dependencies, for instance by adding a single line `libc="*"` to our
|
|||
`Cargo.lock`. Then, `carnix` needs to be run again, and produces the
|
||||
following nix file:
|
||||
|
||||
```
|
||||
```nix
|
||||
# Generated by carnix 0.6.5: carnix -o hello.nix --src ./. Cargo.lock --standalone
|
||||
{ stdenv, buildRustCrate, fetchgit }:
|
||||
let kernel = stdenv.buildPlatform.parsed.kernel.name;
|
||||
|
|
@ -573,7 +574,7 @@ Some crates require external libraries. For crates from
|
|||
Starting from that file, one can add more overrides, to add features
|
||||
or build inputs by overriding the hello crate in a seperate file.
|
||||
|
||||
```
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
((import ./hello.nix).hello {}).override {
|
||||
crateOverrides = defaultCrateOverrides // {
|
||||
|
|
@ -593,7 +594,7 @@ derivation depend on the crate's version, the `attrs` argument of
|
|||
the override above can be read, as in the following example, which
|
||||
patches the derivation:
|
||||
|
||||
```
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
((import ./hello.nix).hello {}).override {
|
||||
crateOverrides = defaultCrateOverrides // {
|
||||
|
|
@ -614,7 +615,7 @@ dependencies. For instance, to override the build inputs for crate
|
|||
`libc` in the example above, where `libc` is a dependency of the main
|
||||
crate, we could do:
|
||||
|
||||
```
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
((import hello.nix).hello {}).override {
|
||||
crateOverrides = defaultCrateOverrides // {
|
||||
|
|
@ -630,27 +631,27 @@ general. A number of other parameters can be overridden:
|
|||
|
||||
- The version of rustc used to compile the crate:
|
||||
|
||||
```
|
||||
```nix
|
||||
(hello {}).override { rust = pkgs.rust; };
|
||||
```
|
||||
|
||||
- Whether to build in release mode or debug mode (release mode by
|
||||
default):
|
||||
|
||||
```
|
||||
```nix
|
||||
(hello {}).override { release = false; };
|
||||
```
|
||||
|
||||
- Whether to print the commands sent to rustc when building
|
||||
(equivalent to `--verbose` in cargo:
|
||||
|
||||
```
|
||||
```nix
|
||||
(hello {}).override { verbose = false; };
|
||||
```
|
||||
|
||||
- Extra arguments to be passed to `rustc`:
|
||||
|
||||
```
|
||||
```nix
|
||||
(hello {}).override { extraRustcOpts = "-Z debuginfo=2"; };
|
||||
```
|
||||
|
||||
|
|
@ -662,7 +663,7 @@ general. A number of other parameters can be overridden:
|
|||
`postInstall`. As an example, here is how to create a new module
|
||||
before running the build script:
|
||||
|
||||
```
|
||||
```nix
|
||||
(hello {}).override {
|
||||
preConfigure = ''
|
||||
echo "pub const PATH=\"${hi.out}\";" >> src/path.rs"
|
||||
|
|
@ -676,7 +677,7 @@ One can also supply features switches. For example, if we want to
|
|||
compile `diesel_cli` only with the `postgres` feature, and no default
|
||||
features, we would write:
|
||||
|
||||
```
|
||||
```nix
|
||||
(callPackage ./diesel.nix {}).diesel {
|
||||
default = false;
|
||||
postgres = true;
|
||||
|
|
@ -699,7 +700,7 @@ Using the example `hello` project above, we want to do the following:
|
|||
|
||||
A typical `shell.nix` might look like:
|
||||
|
||||
```
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
|
||||
stdenv.mkDerivation {
|
||||
|
|
@ -721,7 +722,7 @@ stdenv.mkDerivation {
|
|||
```
|
||||
|
||||
You should now be able to run the following:
|
||||
```
|
||||
```ShellSesssion
|
||||
$ nix-shell --pure
|
||||
$ cargo build
|
||||
$ cargo test
|
||||
|
|
@ -731,7 +732,7 @@ $ cargo test
|
|||
To control your rust version (i.e. use nightly) from within `shell.nix` (or
|
||||
other nix expressions) you can use the following `shell.nix`
|
||||
|
||||
```
|
||||
```nix
|
||||
# Latest Nightly
|
||||
with import <nixpkgs> {};
|
||||
let src = fetchFromGitHub {
|
||||
|
|
@ -759,7 +760,7 @@ stdenv.mkDerivation {
|
|||
```
|
||||
|
||||
Now run:
|
||||
```
|
||||
```ShellSession
|
||||
$ rustc --version
|
||||
rustc 1.26.0-nightly (188e693b3 2018-03-26)
|
||||
```
|
||||
|
|
@ -794,7 +795,7 @@ in the `~/.config/nixpkgs/overlays` directory.
|
|||
|
||||
Add the following to your `configuration.nix`, `home-configuration.nix`, `shell.nix`, or similar:
|
||||
|
||||
```
|
||||
```nix
|
||||
{ pkgs ? import <nixpkgs> {
|
||||
overlays = [
|
||||
(import (builtins.fetchTarball https://github.com/mozilla/nixpkgs-mozilla/archive/master.tar.gz))
|
||||
|
|
|
|||
|
|
@ -156,7 +156,7 @@ assuming that "using latest version" is ok most of the time.
|
|||
|
||||
First create a vim-scripts file having one plugin name per line. Example:
|
||||
|
||||
```
|
||||
```vim
|
||||
"tlib"
|
||||
{'name': 'vim-addon-sql'}
|
||||
{'filetype_regex': '\%(vim)$', 'names': ['reload', 'vim-dev-plugin']}
|
||||
|
|
@ -197,7 +197,7 @@ nix-shell -p vimUtils.vim_with_vim2nix --command "vim -c 'source generate.vim'"
|
|||
You should get a Vim buffer with the nix derivations (output1) and vam.pluginDictionaries (output2).
|
||||
You can add your Vim to your system's configuration file like this and start it by "vim-my":
|
||||
|
||||
```
|
||||
```nix
|
||||
my-vim =
|
||||
let plugins = let inherit (vimUtils) buildVimPluginFrom2Nix; in {
|
||||
copy paste output1 here
|
||||
|
|
@ -217,7 +217,7 @@ my-vim =
|
|||
|
||||
Sample output1:
|
||||
|
||||
```
|
||||
```nix
|
||||
"reload" = buildVimPluginFrom2Nix { # created by nix#NixDerivation
|
||||
name = "reload";
|
||||
src = fetchgit {
|
||||
|
|
@ -248,7 +248,7 @@ Nix expressions for Vim plugins are stored in [pkgs/misc/vim-plugins](/pkgs/misc
|
|||
|
||||
Some plugins require overrides in order to function properly. Overrides are placed in [overrides.nix](/pkgs/misc/vim-plugins/overrides.nix). Overrides are most often required when a plugin requires some dependencies, or extra steps are required during the build process. For example `deoplete-fish` requires both `deoplete-nvim` and `vim-fish`, and so the following override was added:
|
||||
|
||||
```
|
||||
```nix
|
||||
deoplete-fish = super.deoplete-fish.overrideAttrs(old: {
|
||||
dependencies = with super; [ deoplete-nvim vim-fish ];
|
||||
});
|
||||
|
|
|
|||
Loading…
Reference in a new issue