Merge master into haskell-updates
This commit is contained in:
Robert Hensing
@@ -174,7 +174,7 @@ It is a curated set of libraries that:
|
||||
1. Always work together.
|
||||
2. Are as up-to-date as possible.
|
||||
|
||||
While the Haskell ecosystem is huge, and Stackage is highly automatised,
|
||||
While the Haskell ecosystem is huge, and Stackage is highly automated,
|
||||
the Agda package set is small and can (still) be maintained by hand.
|
||||
|
||||
### Adding Agda packages to Nixpkgs {#adding-agda-packages-to-nixpkgs}
|
||||
@@ -203,7 +203,32 @@ Note that the derivation function is called with `mkDerivation` set to `agdaPack
|
||||
could use a similar set as in your `default.nix` from [Writing Agda Packages](#writing-agda-packages) with
|
||||
`agdaPackages.mkDerivation` replaced with `mkDerivation`.
|
||||
|
||||
When writing an Agda package it is essential to make sure that no `.agda-lib` file gets added to the store as a single file (for example by using `writeText`). This causes Agda to think that the nix store is a Agda library and it will attempt to write to it whenever it typechecks something. See [https://github.com/agda/agda/issues/4613](https://github.com/agda/agda/issues/4613).
|
||||
Here is an example skeleton derivation for iowa-stdlib:
|
||||
|
||||
```nix
|
||||
mkDerivation {
|
||||
version = "1.5.0";
|
||||
pname = "iowa-stdlib";
|
||||
|
||||
src = <...>;
|
||||
|
||||
libraryFile = "";
|
||||
libraryName = "IAL-1.3";
|
||||
|
||||
buildPhase = ''
|
||||
runHook preBuild
|
||||
|
||||
patchShebangs find-deps.sh
|
||||
make
|
||||
|
||||
runHook postBuild
|
||||
'';
|
||||
}
|
||||
```
|
||||
|
||||
This library has a file called `.agda-lib`, and so we give an empty string to `libraryFile` as nothing precedes `.agda-lib` in the filename. This file contains `name: IAL-1.3`, and so we let `libraryName = "IAL-1.3"`. This library does not use an `Everything.agda` file and instead has a Makefile, so there is no need to set `everythingFile` and we set a custom `buildPhase`.
|
||||
|
||||
When writing an Agda package, it is essential to make sure that no `.agda-lib` file gets added to the store as a single file (for example by using `writeText`). This causes Agda to think that the nix store is a Agda library and it will attempt to write to it whenever it typechecks something. See [https://github.com/agda/agda/issues/4613](https://githcub.com/agda/agda/issues/4613).
|
||||
|
||||
In the pull request adding this library,
|
||||
you can test whether it builds correctly by writing in a comment:
|
||||
|
||||
@@ -17,7 +17,7 @@ This is identical to:
|
||||
{ buildInputs = [ androidStudioPackages.stable.full ]; }
|
||||
```
|
||||
|
||||
Alternatively, you can pass composeAndroidPackages to the `withSdk` passthru:
|
||||
Alternatively, you can pass composeAndroidPackages to the `withSdk` passthrough:
|
||||
|
||||
```nix
|
||||
{
|
||||
@@ -297,7 +297,7 @@ Note that running Android Studio with ANDROID_HOME set will automatically write
|
||||
`local.properties` file with `sdk.dir` set to $ANDROID_HOME if one does not already
|
||||
exist. If you are using the NDK as well, you may have to add `ndk.dir` to this file.
|
||||
|
||||
An example shell.nix that does all this for you is provided in examples/shell.nix.
|
||||
An example `shell.nix` that does all this for you is provided in `examples/shell.nix`.
|
||||
This shell.nix includes a shell hook that overwrites local.properties with the correct
|
||||
sdk.dir and ndk.dir values. This will ensure that the SDK and NDK directories will
|
||||
both be correct when you run Android Studio inside nix-shell.
|
||||
|
||||
@@ -4,7 +4,7 @@ Astal is a collection of building blocks for creating custom desktop shells.
|
||||
|
||||
## Bundling {#astal-bundling}
|
||||
|
||||
Bundling Astal application is done using `ags` tool, you can use it like this:
|
||||
Bundling an Astal application is done using the `ags` tool. You can use it like this:
|
||||
|
||||
```nix
|
||||
ags.bundle {
|
||||
@@ -19,7 +19,7 @@ ags.bundle {
|
||||
entry = "app.ts";
|
||||
|
||||
dependencies = [
|
||||
# list here astal modules, that your package depends on
|
||||
# list here astal modules that your package depends on
|
||||
# `astal3`, `astal4` and `astal.io` are automatically included
|
||||
astal.apps
|
||||
astal.battery
|
||||
|
||||
@@ -8,7 +8,7 @@ In this document and related Nix expressions, we use the term, _BEAM_, to descri
|
||||
|
||||
### Elixir {#elixir}
|
||||
|
||||
nixpkgs follows the [official elixir deprecation schedule](https://hexdocs.pm/elixir/compatibility-and-deprecations.html) and keeps the last 5 released versions of Elixir available.
|
||||
Nixpkgs follows the [official elixir deprecation schedule](https://hexdocs.pm/elixir/compatibility-and-deprecations.html) and keeps the last 5 released versions of Elixir available.
|
||||
|
||||
## Structure {#beam-structure}
|
||||
|
||||
@@ -89,11 +89,11 @@ Erlang.mk functions similarly to Rebar3, except we use `buildErlangMk` instead o
|
||||
|
||||
#### mixRelease - Elixir Phoenix example {#mix-release-elixir-phoenix-example}
|
||||
|
||||
there are 3 steps, frontend dependencies (javascript), backend dependencies (elixir) and the final derivation that puts both of those together
|
||||
there are 3 steps: frontend dependencies (javascript), backend dependencies (elixir), and the final derivation that puts both of those together
|
||||
|
||||
##### mixRelease - Frontend dependencies (javascript) {#mix-release-javascript-deps}
|
||||
|
||||
For phoenix projects, inside of nixpkgs you can either use yarn2nix (mkYarnModule) or node2nix. An example with yarn2nix can be found [here](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix#L39). An example with node2nix will follow. To package something outside of nixpkgs, you have alternatives like [npmlock2nix](https://github.com/nix-community/npmlock2nix) or [nix-npm-buildpackage](https://github.com/serokell/nix-npm-buildpackage)
|
||||
For phoenix projects, inside of Nixpkgs you can either use yarn2nix (mkYarnModule) or node2nix. An example with yarn2nix can be found [here](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix#L39). An example with node2nix will follow. To package something outside of nixpkgs, you have alternatives like [npmlock2nix](https://github.com/nix-community/npmlock2nix) or [nix-npm-buildpackage](https://github.com/serokell/nix-npm-buildpackage)
|
||||
|
||||
##### mixRelease - backend dependencies (mix) {#mix-release-mix-deps}
|
||||
|
||||
@@ -101,7 +101,7 @@ There are 2 ways to package backend dependencies. With mix2nix and with a fixed-
|
||||
|
||||
###### mix2nix {#mix2nix}
|
||||
|
||||
`mix2nix` is a cli tool available in nixpkgs. it will generate a nix expression from a mix.lock file. It is quite standard in the 2nix tool series.
|
||||
`mix2nix` is a cli tool available in Nixpkgs. It will generate a Nix expression from a `mix.lock` file. It is quite standard in the 2nix tool series.
|
||||
|
||||
Note that currently mix2nix can't handle git dependencies inside the mix.lock file. If you have git dependencies, you can either add them manually (see [example](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/pleroma/default.nix#L20)) or use the FOD method.
|
||||
|
||||
@@ -173,7 +173,7 @@ Note that if after you've replaced the value, nix suggests another hash, then mi
|
||||
|
||||
##### mixRelease - example {#mix-release-example}
|
||||
|
||||
Here is how your `default.nix` file would look for a phoenix project.
|
||||
Here is how your `default.nix` file would look for a Phoenix project.
|
||||
|
||||
```nix
|
||||
with import <nixpkgs> { };
|
||||
@@ -311,7 +311,7 @@ in
|
||||
|
||||
### Creating a Shell {#creating-a-shell}
|
||||
|
||||
Usually, we need to create a `shell.nix` file and do our development inside of the environment specified therein. Just install your version of Erlang and any other interpreters, and then use your normal build tools. As an example with Elixir:
|
||||
Usually, we need to create a `shell.nix` file and do our development inside the environment specified therein. Just install your version of Erlang and any other interpreters, and then use your normal build tools. As an example, with Elixir:
|
||||
|
||||
```nix
|
||||
{
|
||||
@@ -327,7 +327,7 @@ mkShell { buildInputs = [ elixir ]; }
|
||||
|
||||
### Using an overlay {#beam-using-overlays}
|
||||
|
||||
If you need to use an overlay to change some attributes of a derivation, e.g. if you need a bugfix from a version that is not yet available in nixpkgs, you can override attributes such as `version` (and the corresponding `hash`) and then use this overlay in your development environment:
|
||||
If you need to use an overlay to change some attributes of a derivation, e.g. if you need a bugfix from a version that is not yet available in Nixpkgs, you can override attributes such as `version` (and the corresponding `hash`) and then use this overlay in your development environment:
|
||||
|
||||
#### `shell.nix` {#beam-using-overlays-shell.nix}
|
||||
|
||||
@@ -412,4 +412,4 @@ Initializing the project will require the following steps:
|
||||
- create the db `createdb db`
|
||||
- start the postgres instance `pg_ctl -l "$PGDATA/server.log" start`
|
||||
- add the `/db` folder to your `.gitignore`
|
||||
- you can start your phoenix server and get a shell with `iex -S mix phx.server`
|
||||
- you can start your Phoenix server and get a shell with `iex -S mix phx.server`
|
||||
|
||||
@@ -132,7 +132,7 @@ A few notes about [Full example — `default.nix`](#ex-buildBowerComponentsDefau
|
||||
|
||||
1. The result of `buildBowerComponents` is an input to the frontend build.
|
||||
2. Whether to symlink or copy the {file}`bower_components` directory depends on the build tool in use.
|
||||
In this case a copy is used to avoid {command}`gulp` silliness with permissions.
|
||||
In this case, a copy is used to avoid {command}`gulp` silliness with permissions.
|
||||
3. {command}`gulp` requires `HOME` to refer to a writeable directory.
|
||||
4. The actual build command in this example is {command}`gulp`. Other tools could be used instead.
|
||||
|
||||
|
||||
@@ -53,7 +53,7 @@ procedure for updating eggs.
|
||||
## Override Scope {#sec-chicken-override-scope}
|
||||
|
||||
The chicken package and its eggs, respectively, reside in a scope. This means,
|
||||
the scope can be overridden to effect other packages in it.
|
||||
the scope can be overridden to affect other packages in it.
|
||||
|
||||
This example shows how to use a local copy of `srfi-180` and have it affect
|
||||
all the other eggs:
|
||||
@@ -62,7 +62,7 @@ all the other eggs:
|
||||
let
|
||||
myChickenPackages = pkgs.chickenPackages.overrideScope (
|
||||
self: super: {
|
||||
# The chicken package itself can be overridden to effect the whole ecosystem.
|
||||
# The chicken package itself can be overridden to affect the whole ecosystem.
|
||||
# chicken = super.chicken.overrideAttrs {
|
||||
# src = ...
|
||||
# };
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
## Coq derivation: `coq` {#coq-derivation-coq}
|
||||
|
||||
The Coq derivation is overridable through the `coq.override overrides`, where overrides is an attribute set which contains the arguments to override. We recommend overriding either of the following
|
||||
The Coq derivation is overridable through the `coq.override overrides`, where overrides is an attribute set which contains the arguments to override. We recommend overriding either of the following:
|
||||
|
||||
* `version` (optional, defaults to the latest version of Coq selected for nixpkgs, see `pkgs/top-level/coq-packages` to witness this choice), which follows the conventions explained in the `coqPackages` section below,
|
||||
* `customOCamlPackages` (optional, defaults to `null`, which lets Coq choose a version automatically), which can be set to any of the ocaml packages attribute of `ocaml-ng` (such as `ocaml-ng.ocamlPackages_4_10` which is the default for Coq 8.11 for example).
|
||||
|
||||
@@ -265,7 +265,7 @@ By default, the NVIDIA Container Toolkit will use the GPU index to identify spec
|
||||
|
||||
#### Using docker-compose {#cuda-using-docker-compose}
|
||||
|
||||
It's possible to expose GPU's to a `docker-compose` environment as well. With a `docker-compose.yaml` file like follows:
|
||||
It's possible to expose GPUs to a `docker-compose` environment as well. With a `docker-compose.yaml` file like follows:
|
||||
|
||||
```yaml
|
||||
services:
|
||||
|
||||
@@ -25,9 +25,9 @@ cause the generated `pubspec.lock` derivation to rebuild!
|
||||
|
||||
If the package has Git package dependencies, the hashes must be provided in the `gitHashes` set. If a hash is missing, an error message prompting you to add it will be shown.
|
||||
|
||||
The `dart` commands run can be overridden through `pubGetScript` and `dartCompileCommand`, you can also add flags using `dartCompileFlags` or `dartJitFlags`.
|
||||
The `dart` commands run can be overridden through `pubGetScript` and `dartCompileCommand`; you can also add flags using `dartCompileFlags` or `dartJitFlags`.
|
||||
|
||||
Dart supports multiple [outputs types](https://dart.dev/tools/dart-compile#types-of-output), you can choose between them using `dartOutputType` (defaults to `exe`). If you want to override the binaries path or the source path they come from, you can use `dartEntryPoints`. Outputs that require a runtime will automatically be wrapped with the relevant runtime (`dartaotruntime` for `aot-snapshot`, `dart run` for `jit-snapshot` and `kernel`, `node` for `js`), this can be overridden through `dartRuntimeCommand`.
|
||||
Dart supports multiple [outputs types](https://dart.dev/tools/dart-compile#types-of-output); you can choose between them using `dartOutputType` (defaults to `exe`). If you want to override the binaries path or the source path they come from, you can use `dartEntryPoints`. Outputs that require a runtime will automatically be wrapped with the relevant runtime (`dartaotruntime` for `aot-snapshot`, `dart run` for `jit-snapshot` and `kernel`, `node` for `js`); this can be overridden through `dartRuntimeCommand`.
|
||||
|
||||
```nix
|
||||
{
|
||||
@@ -133,7 +133,7 @@ Flutter-specific `nix-shell` usage notes are included here. See the [Dart docume
|
||||
#### Entering the shell {#ssec-dart-flutter-nix-shell-enter}
|
||||
|
||||
By default, dependencies for only the `targetFlutterPlatform` are available in the
|
||||
build environment. This is useful for keeping closures small, but be problematic
|
||||
build environment. This is useful for keeping closures small but can be problematic
|
||||
during development. It's common, for example, to build Web apps for Linux during
|
||||
development to take advantage of native features such as stateful hot reload.
|
||||
|
||||
|
||||
@@ -16,8 +16,8 @@ https://prelude.dhall-lang.org/v20.1.0/package.dhall
|
||||
sha256:26b0ef498663d269e4dc6a82b0ee289ec565d683ef4c00d0ebdd25333a5a3c98
|
||||
```
|
||||
|
||||
… and if the import is cached then the interpreter will load the import from
|
||||
cache instead of fetching the URL.
|
||||
… and if the import is cached, then the interpreter will load the import from
|
||||
the cache instead of fetching the URL.
|
||||
|
||||
Nixpkgs uses this trick to add all of a Dhall expression's dependencies into the
|
||||
cache so that the Dhall interpreter never needs to resolve any remote URLs. In
|
||||
@@ -163,8 +163,8 @@ result
|
||||
```
|
||||
|
||||
The `source.dhall` file is only present for packages that specify
|
||||
`source = true;`. By default, Dhall packages omit the `source.dhall` in order
|
||||
to conserve disk space when they are used exclusively as dependencies. For
|
||||
`source = true;`. By default, Dhall packages omit the `source.dhall` in order
|
||||
to conserve disk space when they are used exclusively as dependencies. For
|
||||
example, if we build the Prelude package it will only contain the binary
|
||||
encoding of the expression:
|
||||
|
||||
@@ -182,7 +182,7 @@ result
|
||||
```
|
||||
|
||||
Typically, you only specify `source = true;` for the top-level Dhall expression
|
||||
of interest (such as our example `true.nix` Dhall package). However, if you
|
||||
of interest (such as our example `true.nix` Dhall package). However, if you
|
||||
wish to specify `source = true` for all Dhall packages, then you can amend the
|
||||
Dhall overlay like this:
|
||||
|
||||
@@ -267,7 +267,7 @@ of `buildDhallPackage` that accepts the following arguments:
|
||||
* `src`: The directory containing Dhall code that you want to turn into a Dhall
|
||||
package
|
||||
|
||||
* `file`: The top-level file (`package.dhall` by default) that is the entrypoint
|
||||
* `file`: The top-level file (`package.dhall` by default) that is the entry point
|
||||
to the rest of the package
|
||||
|
||||
* `document`: Set to `true` to generate documentation for the package
|
||||
@@ -291,7 +291,7 @@ terms of `buildDhallPackage` that accepts the following arguments:
|
||||
directory other than the root of the repository)
|
||||
|
||||
* `file`: The top-level file (`${directory}/package.dhall` by default) that is
|
||||
the entrypoint to the rest of the package
|
||||
the entry point to the rest of the package
|
||||
|
||||
* `document`: Set to `true` to generate documentation for the package
|
||||
|
||||
@@ -410,9 +410,9 @@ error: build of '/nix/store/0f1hla7ff1wiaqyk1r2ky4wnhnw114fi-true.drv' failed
|
||||
```
|
||||
|
||||
… because the default Prelude selected by Nixpkgs revision
|
||||
`94b2848559b12a8ed1fe433084686b2a81123c99is` is version 20.1.0, which doesn't
|
||||
have the same integrity check as version 19.0.0. This means that version
|
||||
19.0.0 is not cached and the interpreter is not allowed to fall back to
|
||||
`94b2848559b12a8ed1fe433084686b2a81123c99` is version 20.1.0, which doesn't
|
||||
have the same integrity check as version 19.0.0. This means that version
|
||||
19.0.0 is not cached, and the interpreter is not allowed to fall back to
|
||||
importing the URL.
|
||||
|
||||
However, we can override the default Prelude version by using `dhall-to-nixpkgs`
|
||||
|
||||
@@ -47,12 +47,12 @@ Note that you need to define `installPhase` because `dub` doesn't know where fil
|
||||
Also note that running `dub test` is disabled by default. You can enable it by setting `doCheck = true`.
|
||||
|
||||
## Lockfiles {#dub-lockfiles}
|
||||
Nixpkgs has its own lockfile format for `dub` dependencies, because `dub`'s official "lockfile" format (`dub.selections.json`) is not hash based.
|
||||
Nixpkgs has its own lockfile format for `dub` dependencies, because `dub`'s official "lockfile" format (`dub.selections.json`) is not hash-based.
|
||||
|
||||
A lockfile can be generated using the `dub-to-nix` helper package.
|
||||
* Firstly, install `dub-to-nix` into your shell session by running `nix-shell -p dub-to-nix`
|
||||
* Then navigate to the root of the source of the program you want to package
|
||||
* Finally, run `dub-to-nix` and it will print the lockfile to stdout. You could pipe stdout into a text file or just copy the output manually into a file.
|
||||
* Firstly, install `dub-to-nix` into your shell session by running `nix-shell -p dub-to-nix`.
|
||||
* Then navigate to the root of the source of the program you want to package.
|
||||
* Finally, run `dub-to-nix`, and it will print the lockfile to stdout. You can pipe stdout into a text file or just copy the output manually into a file.
|
||||
|
||||
## `buildDubPackage` parameters {#builddubpackage-parameters}
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ mkShell {
|
||||
}
|
||||
```
|
||||
|
||||
This will produce a dotnet installation that has the dotnet 8.0 9.0 sdk. The first sdk listed will have it's cli utility present in the resulting environment. Example info output:
|
||||
This will produce a dotnet installation that has the dotnet 8.0 9.0 sdk. The first sdk listed will have its cli utility present in the resulting environment. Example info output:
|
||||
|
||||
```ShellSession
|
||||
$ dotnet --info
|
||||
@@ -121,7 +121,7 @@ For more detail about managing the `deps.json` file, see [Generating and updatin
|
||||
* `buildType` is used to change the type of build. Possible values are `Release`, `Debug`, etc. By default, this is set to `Release`.
|
||||
* `selfContainedBuild` allows to enable the [self-contained](https://docs.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained) build flag. By default, it is set to false and generated applications have a dependency on the selected dotnet runtime. If enabled, the dotnet runtime is bundled into the executable and the built app has no dependency on .NET.
|
||||
* `useAppHost` will enable creation of a binary executable that runs the .NET application using the specified root. More info in [Microsoft docs](https://learn.microsoft.com/en-us/dotnet/core/deploying/#publish-framework-dependent). Enabled by default.
|
||||
* `useDotnetFromEnv` will change the binary wrapper so that it uses the .NET from the environment. The runtime specified by `dotnet-runtime` is given as a fallback in case no .NET is installed in the user's environment. This is most useful for .NET global tools and LSP servers, which often extend the .NET CLI and their runtime should match the users' .NET runtime.
|
||||
* `useDotnetFromEnv` will change the binary wrapper so that it uses the .NET from the environment. The runtime specified by `dotnet-runtime` is given as a fallback in case no .NET is installed in the user's environment. This is most useful for .NET global tools and LSP servers, which often extend the .NET CLI and their runtime should match the user's .NET runtime.
|
||||
* `dotnet-sdk` is useful in cases where you need to change what dotnet SDK is being used. You can also set this to the result of `dotnetSdkPackages.combinePackages`, if the project uses multiple SDKs to build.
|
||||
* `dotnet-runtime` is useful in cases where you need to change what dotnet runtime is being used. This can be either a regular dotnet runtime, or an aspnetcore.
|
||||
* `testProjectFile` is useful in cases where the regular project file does not contain the unit tests. It gets restored and build, but not installed. You may need to regenerate your nuget lockfile after setting this. Note that if set, only tests from this project are executed.
|
||||
@@ -250,13 +250,13 @@ $ dotnet restore --packages out
|
||||
Restored /home/ggg/git-credential-manager/src/shared/Git-Credential-Manager/Git-Credential-Manager.csproj (in 1.21 sec).
|
||||
```
|
||||
|
||||
Next, use `nuget-to-json` tool provided in nixpkgs to generate a lockfile to `deps.json` from
|
||||
Next, use the `nuget-to-json` tool provided in Nixpkgs to generate a lockfile to `deps.json` from
|
||||
the packages inside the `out` directory.
|
||||
|
||||
```bash
|
||||
$ nuget-to-json out > deps.json
|
||||
```
|
||||
Which `nuget-to-json` will generate an output similar to below
|
||||
The `nuget-to-json` tool will generate an output similar to the one below
|
||||
```json
|
||||
[
|
||||
{
|
||||
|
||||
@@ -49,7 +49,7 @@ Its top-level directory must be one (or multiple) of `basis`, `core` or `extra`.
|
||||
`work` is routed to `/var/lib/factor` and is not shipped nor referenced in the nix store, see the section on [scaffolding](#ssec-factor-scaffolding).
|
||||
You should usually use `extra`, but you can use the other roots to overwrite built-in vocabularies.
|
||||
Be aware that vocabularies in `core` are part of the Factor image which the development environment is run from.
|
||||
This means the code in those vocabularies is not loaded from the sources, such that you need to call `refresh-all` to re-compile and load the changed definitions.
|
||||
This means the code in those vocabularies is not loaded from the sources, such that you need to call `refresh-all` to recompile and load the changed definitions.
|
||||
In these instances, it is advised to override the `factor-unwrapped` package directly, which compiles and packages the core Factor libraries into the default Factor
|
||||
image.
|
||||
|
||||
@@ -97,7 +97,7 @@ factorPackages.buildFactorVocab {
|
||||
```
|
||||
|
||||
The vocabulary goes to `lib/factor/extra`, extra files, like licenses etc. would go to `share/` as usual and could be added to the output via a `postInstall` phase.
|
||||
In case the vocabulary binds to a shared library or calls a binary that needs to be present in the runtime environment of its users, add `extraPaths` and `extraLibs` attributes respectively.
|
||||
In case the vocabulary binds to a shared library or calls a binary that needs to be present in the runtime environment of its users, add `extraPaths` and `extraLibs` attributes, respectively.
|
||||
They are then picked up by the `buildFactorApplication` function and added as runtime dependencies.
|
||||
|
||||
## Building Applications {#ssec-factor-applications}
|
||||
@@ -175,7 +175,7 @@ factorPackages.buildFactorApplication (finalAttrs: {
|
||||
})
|
||||
```
|
||||
|
||||
The use of the `src.name` and`sourceRoot` attributes conveniently establish the necessary `painter` vocabulary directory that is needed for the deployment to work.
|
||||
The use of the `src.name` and `sourceRoot` attributes conveniently establish the necessary `painter` vocabulary directory that is needed for the deployment to work.
|
||||
|
||||
It requires the packager to specify the full set of binaries to be made available at runtime.
|
||||
This enables the standard pattern for application packages to specify all runtime dependencies explicitly without the Factor runtime interfering.
|
||||
|
||||
@@ -67,7 +67,7 @@ To avoid updating this field when dependencies change, run `go mod vendor` in yo
|
||||
You can read more about [vendoring in the Go documentation](https://go.dev/ref/mod#vendoring).
|
||||
|
||||
To obtain the hash, set `vendorHash = lib.fakeHash;` and run the build. ([more details here](#sec-source-hashes)).
|
||||
Another way is to use use `nix-prefetch` to obtain the hash. The following command gets the value of `vendorHash` for package `pet`:
|
||||
Another way is to use `nix-prefetch` to obtain the hash. The following command gets the value of `vendorHash` for package `pet`:
|
||||
|
||||
|
||||
```sh
|
||||
@@ -108,7 +108,7 @@ Defaults to `false`.
|
||||
### `modPostBuild` {#var-go-modPostBuild}
|
||||
|
||||
Shell commands to run after the build of the goModules executes `go mod vendor`, and before calculating fixed output derivation's `vendorHash`.
|
||||
Note that if you change this attribute, you need to update `vendorHash` attribute.
|
||||
Note that if you change this attribute, you need to update the `vendorHash` attribute.
|
||||
|
||||
|
||||
### `modRoot` {#var-go-modRoot}
|
||||
@@ -197,7 +197,7 @@ Defaults to `null`
|
||||
|
||||
Beside `buildGoModule`, there are also versioned builders available that pin a specific Go version, like `buildGo124Module` for Go 1.24.
|
||||
Similar, versioned toolchains are available, like `go_1_24` for Go 1.24.
|
||||
Both builder and toolchain of a certain version will be removed as soon as the Go version reaches end of life.
|
||||
Both builder and toolchain of a certain version will be removed as soon as the Go version reaches its end of life.
|
||||
|
||||
As toolchain updates in nixpkgs cause mass rebuilds and must go through the staging cycle, it can take a while until a new Go minor version is available to consumers of nixpkgs.
|
||||
If you want quicker access to the latest minor, use `go_latest` toolchain and `buildGoLatestModule` builder.
|
||||
@@ -248,7 +248,7 @@ The Go build can be further tweaked by setting environment variables via the `en
|
||||
|
||||
### `env.CGO_ENABLED` {#var-go-CGO_ENABLED}
|
||||
|
||||
When set to `0`, the [cgo](https://pkg.go.dev/cmd/cgo) command is disabled. As consequence, the build
|
||||
When set to `0`, the [cgo](https://pkg.go.dev/cmd/cgo) command is disabled. As a consequence, the build
|
||||
program can't link against C libraries anymore, and the resulting binary is statically linked.
|
||||
|
||||
When building with CGO enabled, Go will likely link some packages from the Go standard library against C libraries,
|
||||
|
||||
@@ -7,7 +7,7 @@ record dependencies so they can be restored in a reproducible fashion.
|
||||
|
||||
## Building a Gradle package {#building-a-gradle-package}
|
||||
|
||||
Here's how a typical derivation will look like:
|
||||
Here's how a typical derivation will look:
|
||||
|
||||
```nix
|
||||
stdenv.mkDerivation (finalAttrs: {
|
||||
@@ -69,7 +69,7 @@ If your package can't be evaluated using a simple `pkgs.<pname>`
|
||||
expression (for example, if your package isn't located in nixpkgs, or if
|
||||
you want to override some of its attributes), you will usually have to
|
||||
pass `pkg` instead of `pname` to `gradle.fetchDeps`. There are two ways
|
||||
of doing it.
|
||||
of doing so.
|
||||
|
||||
The first is to add the derivation arguments required for getting the
|
||||
package. Using the pdftk example above:
|
||||
|
||||
@@ -17,7 +17,7 @@ The compiler and most build tools are exposed at the top level:
|
||||
* `ghc` is the default version of GHC
|
||||
* Language specific tools: `cabal-install`, `stack`, `hpack`, …
|
||||
|
||||
Many “normal” user facing packages written in Haskell, like `niv` or `cachix`,
|
||||
Many “normal” user-facing packages written in Haskell, like `niv` or `cachix`,
|
||||
are also exposed at the top level, and there is nothing Haskell specific to
|
||||
installing and using them.
|
||||
|
||||
@@ -57,7 +57,7 @@ Available compilers are collected under `haskell.compiler`.
|
||||
Each of those compiler versions has a corresponding attribute set `packages` built with
|
||||
it. However, the non-standard package sets are not tested regularly and, as a
|
||||
result, contain fewer working packages. The corresponding package set for GHC
|
||||
9.4.8 is `haskell.packages.ghc948`. In fact `haskellPackages` (at the time of writing) is just an alias
|
||||
9.4.8 is `haskell.packages.ghc948`. In fact, `haskellPackages` (at the time of writing) is just an alias
|
||||
for `haskell.packages.ghc9102`:
|
||||
|
||||
Every package set also re-exposes the GHC used to build its packages as `haskell.packages.*.ghc`.
|
||||
@@ -110,12 +110,12 @@ files to loosen this a bit.
|
||||
|
||||
Normally when you build Haskell packages with `cabal-install`, `cabal-install`
|
||||
does dependency resolution. It will look at all Haskell package versions known
|
||||
on Hackage and tries to pick for every (transitive) dependency of your build
|
||||
on Hackage and try to pick for every (transitive) dependency of your build
|
||||
exactly one version. Those versions need to satisfy all the version constraints
|
||||
given in the `.cabal` file of your package and all its dependencies.
|
||||
|
||||
The [Haskell builder in nixpkgs](#haskell-mkderivation) does no such thing.
|
||||
It will take as input packages with names off the desired dependencies
|
||||
It will take as input packages with names of the desired dependencies
|
||||
and just check whether they fulfill the version bounds and fail if they don’t
|
||||
(by default, see `jailbreak` to circumvent this).
|
||||
|
||||
@@ -131,8 +131,8 @@ for a specific package, see
|
||||
### Limitations {#haskell-limitations}
|
||||
|
||||
Our main objective with `haskellPackages` is to package Haskell software in
|
||||
nixpkgs. This entails some limitations, partially due to self-imposed
|
||||
restrictions of nixpkgs, partially in the name of maintainability:
|
||||
Nixpkgs. This entails some limitations, partially due to self-imposed
|
||||
restrictions of Nixpkgs, partially in the name of maintainability:
|
||||
|
||||
* Only the packages built with the default compiler see extensive testing of the
|
||||
whole package set. For other GHC versions only a few essential packages are
|
||||
@@ -184,7 +184,7 @@ Older minor versions for a supported major version will only be kept, if they ar
|
||||
|
||||
## `haskellPackages.mkDerivation` {#haskell-mkderivation}
|
||||
|
||||
Every haskell package set has its own haskell-aware `mkDerivation` which is used
|
||||
Every Haskell package set has its own Haskell-aware `mkDerivation` which is used
|
||||
to build its packages. Generally you won't have to interact with this builder
|
||||
since [cabal2nix](#haskell-cabal2nix) can generate packages
|
||||
using it for an arbitrary cabal package definition. Still it is useful to know
|
||||
@@ -192,7 +192,7 @@ the parameters it takes when you need to
|
||||
[override](#haskell-overriding-haskell-packages) a generated Nix expression.
|
||||
|
||||
`haskellPackages.mkDerivation` is a wrapper around `stdenv.mkDerivation` which
|
||||
re-defines the default phases to be haskell aware and handles dependency
|
||||
re-defines the default phases to be Haskell-aware and handles dependency
|
||||
specification, test suites, benchmarks etc. by compiling and invoking the
|
||||
package's `Setup.hs`. It does *not* use or invoke the `cabal-install` binary,
|
||||
but uses the underlying `Cabal` library instead.
|
||||
@@ -541,7 +541,7 @@ turtle-incremental-build
|
||||
|
||||
## Development environments {#haskell-development-environments}
|
||||
|
||||
In addition to building and installing Haskell software, nixpkgs can also
|
||||
In addition to building and installing Haskell software, Nixpkgs can also
|
||||
provide development environments for Haskell projects. This has the obvious
|
||||
advantage that you benefit from `cache.nixos.org` and no longer need to compile
|
||||
all project dependencies yourself. While it is often very useful, this is not
|
||||
@@ -720,7 +720,7 @@ pkgs.haskellPackages.shellFor {
|
||||
|
||||
### haskell-language-server {#haskell-language-server}
|
||||
|
||||
To use HLS in short: Install `pkgs.haskell-language-server` e.g. in
|
||||
To use HLS in short: Install `pkgs.haskell-language-server`, e.g. in
|
||||
`nativeBuildInputs` in `shellFor` and use the `haskell-language-server-wrapper`
|
||||
command to run it. See the [HLS user guide] on how to configure your text
|
||||
editor to use HLS and how to test your setup.
|
||||
@@ -754,7 +754,7 @@ stack) and pick the appropriate versioned binary from your path.
|
||||
|
||||
Be careful when installing HLS globally and using a pinned nixpkgs for a
|
||||
Haskell project in a `nix-shell`. If the nixpkgs versions deviate to much
|
||||
(e.g., use different `glibc` versions) the `haskell-language-server-?.?.?`
|
||||
(e.g., use different `glibc` versions) the `haskell-language-server-?.?.?`
|
||||
executable will try to detect these situations and refuse to start. It is
|
||||
recommended to obtain HLS via `nix-shell` from the nixpkgs version pinned in
|
||||
there instead.
|
||||
|
||||
@@ -12,9 +12,9 @@ Packages that are installed with your python derivation, are not accessible by `
|
||||
|
||||
### Installation with packages {#installation-with-packages}
|
||||
|
||||
Creating `hy` derivation with custom `python` packages is really simple and similar to the way that python does it. Attribute `hy` provides function `withPackages` that creates custom `hy` derivation with specified packages.
|
||||
Creating a `hy` derivation with custom `python` packages is really simple and similar to the way that python does it. The attribute `hy` provides the function `withPackages` that creates a custom `hy` derivation with specified packages.
|
||||
|
||||
For example if you want to create shell with `matplotlib` and `numpy`, you can do it like so:
|
||||
For example, if you want to create a shell with `matplotlib` and `numpy`, you can do it like so:
|
||||
|
||||
```ShellSession
|
||||
$ nix-shell -p "hy.withPackages (ps: with ps; [ numpy matplotlib ])"
|
||||
|
||||
@@ -24,7 +24,7 @@ in
|
||||
lspLibPkg.library { withSource = true; }
|
||||
```
|
||||
|
||||
The above results in a derivation with the installed library results (with sourcecode).
|
||||
The above results in a derivation with the installed library results (with source code).
|
||||
|
||||
A slightly more involved example of a fully packaged executable would be the [`idris2-lsp`](https://github.com/idris-community/idris2-lsp) which is an Idris2 language server that uses the `LSP-lib` found above.
|
||||
```nix
|
||||
|
||||
@@ -103,7 +103,7 @@ The above function takes a variety of parameters:
|
||||
It also possible to adjust the `xcodebuild` parameters. This is only needed in
|
||||
rare circumstances. In most cases the default values should suffice:
|
||||
|
||||
* Specifies which `xcodebuild` target to build. By default it takes the target
|
||||
* `target` specifies which `xcodebuild` target to build. By default it takes the target
|
||||
that has the same name as the app.
|
||||
* The `configuration` parameter can be overridden if desired. By default, it
|
||||
will do a debug build for the simulator and a release build for real devices.
|
||||
@@ -120,7 +120,7 @@ In addition, you need to set the following parameters:
|
||||
|
||||
* `certificateFile` refers to a P12 certificate file.
|
||||
* `certificatePassword` specifies the password of the P12 certificate.
|
||||
* `provisioningProfile` refers to the provision profile needed to sign the app
|
||||
* `provisioningProfile` refers to the provisioning profile needed to sign the app
|
||||
* `signMethod` should refer to `ad-hoc` for signing the app with an ad-hoc
|
||||
certificate, `enterprise` for enterprise certificates and `app-store` for App
|
||||
store certificates.
|
||||
|
||||
@@ -42,7 +42,7 @@ generated `.jar` files to be non-deterministic, which is not optimal.
|
||||
Using it, however, does not always guarantee reproducibility.
|
||||
|
||||
JAR files that are intended to be used by other packages should be
|
||||
installed in `$out/share/java`. JDKs have a stdenv setup hook that add
|
||||
installed in `$out/share/java`. JDKs have a `stdenv` setup hook that adds
|
||||
any JARs in the `share/java` directories of the build inputs to the
|
||||
`CLASSPATH` environment variable. For instance, if the package `libfoo`
|
||||
installs a JAR named `foo.jar` in its `share/java` directory, and
|
||||
@@ -84,7 +84,7 @@ Since the introduction of the Java Platform Module System in Java 9,
|
||||
Java distributions typically no longer ship with a general-purpose JRE:
|
||||
instead, they allow generating a JRE with only the modules required for
|
||||
your application(s). Because we can't predict what modules will be
|
||||
needed on a general-purpose system, the default jre package is the full
|
||||
needed on a general-purpose system, the default `jre` package is the full
|
||||
JDK. When building a minimal system/image, you can override the
|
||||
`modules` parameter on `jre_minimal` to build a JRE with only the
|
||||
modules relevant for you:
|
||||
|
||||
@@ -2,15 +2,15 @@
|
||||
|
||||
## Introduction {#javascript-introduction}
|
||||
|
||||
This contains instructions on how to package javascript applications.
|
||||
This contains instructions on how to package JavaScript applications.
|
||||
|
||||
The various tools available will be listed in the [tools-overview](#javascript-tools-overview).
|
||||
Some general principles for packaging will follow.
|
||||
Finally some tool specific instructions will be given.
|
||||
Finally, some tool-specific instructions will be given.
|
||||
|
||||
## Getting unstuck / finding code examples {#javascript-finding-examples}
|
||||
|
||||
If you find you are lacking inspiration for packaging javascript applications, the links below might prove useful.
|
||||
If you find you are lacking inspiration for packaging JavaScript applications, the links below might prove useful.
|
||||
Searching online for prior art can be helpful if you are running into solved problems.
|
||||
|
||||
### Github {#javascript-finding-examples-github}
|
||||
@@ -43,17 +43,17 @@ A lock file (package-lock.json, yarn.lock...) is supposed to make reproducible i
|
||||
Guidelines of package managers, recommend to commit those lock files to the repos.
|
||||
If a particular lock file is present, it is a strong indication of which package manager is used upstream.
|
||||
|
||||
It's better to try to use a Nix tool that understand the lock file.
|
||||
Using a different tool might give you hard to understand error because different packages have been installed.
|
||||
It's better to try to use a Nix tool that understands the lock file.
|
||||
Using a different tool might give you a hard-to-understand error because different packages have been installed.
|
||||
An example of problems that could arise can be found [here](https://github.com/NixOS/nixpkgs/pull/126629).
|
||||
Upstream use npm, but this is an attempt to package it with `yarn2nix` (that uses yarn.lock).
|
||||
|
||||
Using a different tool forces to commit a lock file to the repository.
|
||||
Those files are fairly large, so when packaging for nixpkgs, this approach does not scale well.
|
||||
Using a different tool forces you to commit a lock file to the repository.
|
||||
These files are fairly large, so when packaging for nixpkgs, this approach does not scale well.
|
||||
|
||||
Exceptions to this rule are:
|
||||
|
||||
- When you encounter one of the bugs from a Nix tool. In each of the tool specific instructions, known problems will be detailed. If you have a problem with a particular tool, then it's best to try another tool, even if this means you will have to recreate a lock file and commit it to nixpkgs. In general `yarn2nix` has less known problems and so a simple search in nixpkgs will reveal many yarn.lock files committed.
|
||||
- When you encounter one of the bugs from a Nix tool. In each of the tool-specific instructions, known problems will be detailed. If you have a problem with a particular tool, then it's best to try another tool, even if this means you will have to re-create a lock file and commit it to Nixpkgs. In general `yarn2nix` has fewer known problems, and so a simple search in Nixpkgs will reveal many `yarn.lock` files committed.
|
||||
- Some lock files contain particular version of a package that has been pulled off npm for some reason. In that case, you can recreate upstream lock (by removing the original and `npm install`, `yarn`, ...) and commit this to nixpkgs.
|
||||
- The only tool that supports workspaces (a feature of npm that helps manage sub-directories with different package.json from a single top level package.json) is `yarn2nix`. If upstream has workspaces you should try `yarn2nix`.
|
||||
|
||||
@@ -61,7 +61,7 @@ Exceptions to this rule are:
|
||||
|
||||
Exceptions to this rule are:
|
||||
|
||||
- Sometimes the upstream repo assumes some dependencies be installed globally. In that case you can add them manually to the upstream package.json (`yarn add xxx` or `npm install xxx`, ...). Dependencies that are installed locally can be executed with `npx` for CLI tools. (e.g. `npx postcss ...`, this is how you can call those dependencies in the phases).
|
||||
- Sometimes the upstream repo assumes some dependencies should be installed globally. In that case, you can add them manually to the upstream `package.json` (`yarn add xxx` or `npm install xxx`, ...). Dependencies that are installed locally can be executed with `npx` for CLI tools (e.g. `npx postcss ...`, this is how you can call those dependencies in the phases).
|
||||
- Sometimes there is a version conflict between some dependency requirements. In that case you can fix a version by removing the `^`.
|
||||
- Sometimes the script defined in the package.json does not work as is. Some scripts for example use CLI tools that might not be available, or cd in directory with a different package.json (for workspaces notably). In that case, it's perfectly fine to look at what the particular script is doing and break this down in the phases. In the build script you can see `build:*` calling in turns several other build scripts like `build:ui` or `build:server`. If one of those fails, you can try to separate those into,
|
||||
|
||||
@@ -99,7 +99,7 @@ Then when building the frontend you can just symlink the node_modules directory.
|
||||
|
||||
The [pkgs/development/node-packages](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages) folder contains a generated collection of [npm packages](https://npmjs.com/) that can be installed with the Nix package manager.
|
||||
|
||||
As a rule of thumb, the package set should only provide _end user_ software packages, such as command-line utilities.
|
||||
As a rule of thumb, the package set should only provide _end-user_ software packages, such as command-line utilities.
|
||||
Libraries should only be added to the package set if there is a non-npm package that requires it.
|
||||
|
||||
When it is desired to use npm libraries in a development project, use the `node2nix` generator directly on the `package.json` configuration file of the project.
|
||||
@@ -132,9 +132,9 @@ For example, `dat` requires `node-gyp-build`, so we override its expression in [
|
||||
}
|
||||
```
|
||||
|
||||
### Adding and Updating Javascript packages in nixpkgs {#javascript-adding-or-updating-packages}
|
||||
### Adding and updating JavaScript packages in Nixpkgs {#javascript-adding-or-updating-packages}
|
||||
|
||||
To add a package from npm to nixpkgs:
|
||||
To add a package from npm to Nixpkgs:
|
||||
|
||||
1. Modify [pkgs/development/node-packages/node-packages.json](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/node-packages.json) to add, update or remove package entries to have it included in `nodePackages` and `nodePackages_latest`.
|
||||
2. Run the script:
|
||||
@@ -161,7 +161,7 @@ To add a package from npm to nixpkgs:
|
||||
|
||||
For more information about the generation process, consult the [README.md](https://github.com/svanderburg/node2nix) file of the `node2nix` tool.
|
||||
|
||||
To update npm packages in nixpkgs, run the same `generate.sh` script:
|
||||
To update npm packages in Nixpkgs, run the same `generate.sh` script:
|
||||
|
||||
```sh
|
||||
./pkgs/development/node-packages/generate.sh
|
||||
@@ -182,7 +182,7 @@ Use the following Git configuration to resolve the issue:
|
||||
git config --global url."https://github.com/".insteadOf git://github.com/
|
||||
```
|
||||
|
||||
## Tool specific instructions {#javascript-tool-specific}
|
||||
## Tool-specific instructions {#javascript-tool-specific}
|
||||
|
||||
### buildNpmPackage {#javascript-buildNpmPackage}
|
||||
|
||||
@@ -381,7 +381,7 @@ pkgs.mkShell {
|
||||
will create a development shell where a `node_modules` directory is created & packages symlinked to the Nix store when activated.
|
||||
|
||||
:::{.note}
|
||||
Commands like `npm install` & `npm add` that writes packages & executables needs to be used with `--package-lock-only`.
|
||||
Commands like `npm install` & `npm add` that write packages & executables need to be used with `--package-lock-only`.
|
||||
|
||||
This means `npm` installs dependencies by writing into `package-lock.json` without modifying the `node_modules` folder. Installation happens through reloading the devShell.
|
||||
This might be best practice since it gives the `nix shell` virtually exclusive ownership over your `node_modules` folder.
|
||||
@@ -416,7 +416,7 @@ See `node2nix` [docs](https://github.com/svanderburg/node2nix) for more info.
|
||||
|
||||
Pnpm is available as the top-level package `pnpm`. Additionally, there are variants pinned to certain major versions, like `pnpm_8` and `pnpm_9`, which support different sets of lock file versions.
|
||||
|
||||
When packaging an application that includes a `pnpm-lock.yaml`, you need to fetch the pnpm store for that project using a fixed-output-derivation. The functions `pnpm_8.fetchDeps` and `pnpm_9.fetchDeps` can create this pnpm store derivation. In conjunction, the setup hooks `pnpm_8.configHook` and `pnpm_9.configHook` will prepare the build environment to install the prefetched dependencies store. Here is an example for a package that contains a `package.json` and a `pnpm-lock.yaml` files using the above `pnpm_` attributes:
|
||||
When packaging an application that includes a `pnpm-lock.yaml`, you need to fetch the pnpm store for that project using a fixed-output-derivation. The functions `pnpm_8.fetchDeps` and `pnpm_9.fetchDeps` can create this pnpm store derivation. In conjunction, the setup hooks `pnpm_8.configHook` and `pnpm_9.configHook` will prepare the build environment to install the pre-fetched dependencies store. Here is an example for a package that contains `package.json` and a `pnpm-lock.yaml` files using the above `pnpm_` attributes:
|
||||
|
||||
```nix
|
||||
{
|
||||
@@ -447,9 +447,9 @@ stdenv.mkDerivation (finalAttrs: {
|
||||
})
|
||||
```
|
||||
|
||||
NOTE: It is highly recommended to use a pinned version of pnpm (i.e. `pnpm_8` or `pnpm_9`), to increase future reproducibility. It might also be required to use an older version, if the package needs support for a certain lock file version.
|
||||
NOTE: It is highly recommended to use a pinned version of pnpm (i.e., `pnpm_8` or `pnpm_9`), to increase future reproducibility. It might also be required to use an older version if the package needs support for a certain lock file version.
|
||||
|
||||
In case you are patching `package.json` or `pnpm-lock.yaml`, make sure to pass `finalAttrs.patches` to the function as well (i.e. `inherit (finalAttrs) patches`.
|
||||
In case you are patching `package.json` or `pnpm-lock.yaml`, make sure to pass `finalAttrs.patches` to the function as well (i.e., `inherit (finalAttrs) patches`.
|
||||
|
||||
`pnpm.configHook` supports adding additional `pnpm install` flags via `pnpmInstallFlags` which can be set to a Nix string array:
|
||||
|
||||
@@ -520,7 +520,7 @@ For example:
|
||||
The above would make `pnpm.fetchDeps` call only install dependencies for the `@astrojs/language-server` workspace package.
|
||||
Note that you do not need to set `sourceRoot` to make this work.
|
||||
|
||||
Usually in such cases, you'd want to use `pnpm --filter=<pnpm workspace name> build` to build your project, as `npmHooks.npmBuildHook` probably won't work. A `buildPhase` based on the following example will probably fit most workspace projects:
|
||||
Usually, in such cases, you'd want to use `pnpm --filter=<pnpm workspace name> build` to build your project, as `npmHooks.npmBuildHook` probably won't work. A `buildPhase` based on the following example will probably fit most workspace projects:
|
||||
|
||||
```nix
|
||||
{
|
||||
@@ -687,7 +687,7 @@ If the downloaded files contain the `package.json` and `yarn.lock` files they ca
|
||||
|
||||
##### mkYarnPackage {#javascript-yarn2nix-mkYarnPackage}
|
||||
|
||||
`mkYarnPackage` will by default try to generate a binary. For package only generating static assets (Svelte, Vue, React, WebPack, ...), you will need to explicitly override the build step with your instructions.
|
||||
`mkYarnPackage` will by default try to generate a binary. For packages only generating static assets (Svelte, Vue, React, Webpack, ...), you will need to explicitly override the build step with your instructions.
|
||||
|
||||
It's important to use the `--offline` flag. For example if you script is `"build": "something"` in `package.json` use:
|
||||
|
||||
@@ -711,7 +711,7 @@ The `distPhase` is packing the package's dependencies in a tarball using `yarn p
|
||||
{ doDist = false; }
|
||||
```
|
||||
|
||||
The configure phase can sometimes fail because it makes many assumptions which may not always apply. One common override is:
|
||||
The configure phase can sometimes fail because it makes many assumptions that may not always apply. One common override is:
|
||||
|
||||
```nix
|
||||
{
|
||||
@@ -743,7 +743,7 @@ or if you need a writeable node_modules directory:
|
||||
##### mkYarnModules {#javascript-yarn2nix-mkYarnModules}
|
||||
|
||||
This will generate a derivation including the `node_modules` directory.
|
||||
If you have to build a derivation for an integrated web framework (rails, phoenix..), this is probably the easiest way.
|
||||
If you have to build a derivation for an integrated web framework (Rails, Phoenix, etc.), this is probably the easiest way.
|
||||
|
||||
#### Overriding dependency behavior {#javascript-mkYarnPackage-overriding-dependencies}
|
||||
|
||||
@@ -866,7 +866,7 @@ This prints the hash to stdout and can be used in update scripts to recalculate
|
||||
Internally, this uses a patched version of Yarn to ensure git dependencies are re-packed and any attempted downloads fail immediately.
|
||||
|
||||
##### Patching upstream `package.json` or `yarn.lock` files {#javascript-yarnBerry-patching}
|
||||
In case patching the upstream `package.json` or `yarn.lock` is needed, it's important to pass `finalAttrs.patches` to `fetchYarnBerryDeps` as well, so the patched variants are picked up (i.e. `inherit (finalAttrs) patches`.
|
||||
In case patching the upstream `package.json` or `yarn.lock` is needed, it's important to pass `finalAttrs.patches` to `fetchYarnBerryDeps` as well, so the patched variants are picked up (i.e., `inherit (finalAttrs) patches`.
|
||||
|
||||
##### Missing hashes in the `yarn.lock` file {#javascript-yarnBerry-missing-hashes}
|
||||
Unfortunately, `yarn.lock` files do not include hashes for optional/platform-specific dependencies. This is [by design](https://github.com/yarnpkg/berry/issues/6759).
|
||||
@@ -908,7 +908,7 @@ stdenv.mkDerivation (finalAttrs: {
|
||||
## Outside Nixpkgs {#javascript-outside-nixpkgs}
|
||||
|
||||
There are some other tools available, which are written in the Nix language.
|
||||
These that can't be used inside Nixpkgs because they require [Import From Derivation](#ssec-import-from-derivation), which is not allowed in Nixpkgs.
|
||||
These can't be used inside Nixpkgs because they require [Import From Derivation](#ssec-import-from-derivation), which is not allowed in Nixpkgs.
|
||||
|
||||
If you are packaging something outside Nixpkgs, consider the following:
|
||||
|
||||
|
||||
@@ -75,7 +75,7 @@ nix-shell -p 'julia.withPackages ["Plots"]' --run julia
|
||||
different CPUs.
|
||||
|
||||
Why? Julia will detect the CPU microarchitecture of the build machine and include this information in the precompiled
|
||||
`*.ji` files. Starting in 1.10 Julia became more strict about checking the CPU target compatibility, so it may reject
|
||||
`*.ji` files. Starting in 1.10, Julia became more strict about checking the CPU target compatibility, so it may reject
|
||||
your precompiled files if they were compiled on a different machine.
|
||||
A good option to provide wide compatibility is to set this to `"generic"`, although this may reduce performance.
|
||||
You can also set a semicolon-separated list of multiple different targets. See the Julia documentation for details.
|
||||
|
||||
@@ -20,7 +20,7 @@ The `withPackages` function is of primary utility. It is used to build
|
||||
[runnable wrappers](#lisp-building-wrappers), with a pinned and pre-built
|
||||
[ASDF FASL](#lisp-loading-asdf) available in the `ASDF` environment variable,
|
||||
and `CL_SOURCE_REGISTRY`/`ASDF_OUTPUT_TRANSLATIONS` configured to
|
||||
[find the desired systems on runtime](#lisp-loading-systems).
|
||||
[find the desired systems at runtime](#lisp-loading-systems).
|
||||
|
||||
In addition, Lisps have the `withOverrides` function, which can be used to
|
||||
[substitute](#lisp-including-external-pkg-in-scope) any package in the scope of
|
||||
@@ -223,7 +223,7 @@ argument to the `build-asdf-system`/`buildASDFSystem` functions.
|
||||
|
||||
The reason is that ASDF searches for a secondary system in the `.asd` of the
|
||||
parent package. Thus, having them separate would cause either one of them not to
|
||||
load cleanly, because one will contains FASLs of itself but not the other, and
|
||||
load cleanly, because one will contain FASLs of itself but not the other, and
|
||||
vice versa.
|
||||
|
||||
To package slashy systems, use `overrideLispAttrs`, like so:
|
||||
@@ -240,7 +240,7 @@ See the [respective section](#lisp-including-external-pkg-in-scope) on using
|
||||
|
||||
Note that sometimes the slashy systems might not only have more dependencies
|
||||
than the main one, but create a circular dependency between `.asd`
|
||||
files. Unfortunately, in this case an adhoc solution becomes necessary.
|
||||
files. Unfortunately, in this case an ad-hoc solution becomes necessary.
|
||||
|
||||
## Building Wrappers {#lisp-building-wrappers}
|
||||
|
||||
@@ -262,7 +262,7 @@ $ sbcl
|
||||
|
||||
### Loading ASDF {#lisp-loading-asdf}
|
||||
|
||||
For best results, avoid calling `(require 'asdf)` When using the
|
||||
For best results, avoid calling `(require 'asdf)` when using the
|
||||
library-generated wrappers.
|
||||
|
||||
Use `(load (ext:getenv "ASDF"))` instead, supplying your implementation's way of
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Maven {#maven}
|
||||
|
||||
Maven is a well-known build tool for the Java ecosystem however it has some challenges when integrating into the Nix build system.
|
||||
Maven is a well-known build tool for the Java ecosystem; however, it has some challenges when integrating into the Nix build system.
|
||||
|
||||
The following provides a list of common patterns with how to package a Maven project (or any JVM language that can export to Maven) as a Nix package.
|
||||
|
||||
@@ -354,7 +354,7 @@ Some additional files are deleted that would cause the output hash to change pot
|
||||
│ │ ├── classworlds-1.1.jar
|
||||
```
|
||||
|
||||
If your package uses _SNAPSHOT_ dependencies or _version ranges_; there is a strong likelihood that over-time your output hash will change since the resolved dependencies may change. Hence this method is less recommended then using `buildMaven`.
|
||||
If your package uses _SNAPSHOT_ dependencies or _version ranges_; there is a strong likelihood that over time, your output hash will change since the resolved dependencies may change. Hence this method is less recommended than using `buildMaven`.
|
||||
|
||||
### Building a JAR {#building-a-jar}
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Neovim {#neovim}
|
||||
|
||||
Install `neovim-unwrapped` to get a barebone neovim to configure imperatively.
|
||||
Install `neovim-unwrapped` to get a bare-bones Neovim to configure imperatively.
|
||||
This is the closest to what you encounter on other distributions.
|
||||
|
||||
`neovim` is a wrapper around neovim with some extra configuration to for
|
||||
instance set the various language providers like python.
|
||||
`neovim` is a wrapper around Neovim with some extra configuration, for
|
||||
instance, to set the various language providers like Python.
|
||||
The wrapper can be further configured to include your favorite plugins and
|
||||
configurations for a reproducible neovim across machines.
|
||||
See the next section for more details.
|
||||
@@ -52,7 +52,7 @@ neovim-qt.override {
|
||||
```
|
||||
|
||||
You can use the new unstable wrapper but the interface may change:
|
||||
- `autoconfigure`: certain plugins need a custom configuration to work with nix.
|
||||
- `autoconfigure`: certain plugins need a custom configuration to work with Nix.
|
||||
For instance, `sqlite-lua` needs `g:sqlite_clib_path` to be set to work. Nixpkgs historically patched these in the plugins with several drawbacks: harder maintenance and making upstream work harder. Per convention, these mandatory bits of configuration are bookmarked in nixpkgs in `passthru.initLua`. Enabling `autoconfigure` automatically adds the snippets required for the plugins to work.
|
||||
- `autowrapRuntimeDeps`: Appends plugin's runtime dependencies to `PATH`. For instance, `rest.nvim` requires `curl` to work. Enabling `autowrapRuntimeDeps` adds it to the `PATH` visible by your Neovim wrapper (but not your global `PATH`).
|
||||
- `luaRcContent`: Extra lua code to add to the generated `init.lua`.
|
||||
@@ -107,12 +107,12 @@ needs the path towards a unicode database so we expose the following snippet `vi
|
||||
|
||||
#### LuaRocks based plugins {#neovim-luarocks-based-plugins}
|
||||
|
||||
In order to automatically handle plugin dependencies, several neovim plugins
|
||||
In order to automatically handle plugin dependencies, several Neovim plugins
|
||||
upload their package to [LuaRocks](https://www.luarocks.org). This means less work for nixpkgs maintainers in the long term as dependencies get updated automatically.
|
||||
This means several neovim plugins are first packaged as nixpkgs [lua
|
||||
This means several Neovim plugins are first packaged as nixpkgs [lua
|
||||
packages](#packaging-a-library-on-luarocks), and converted via `buildNeovimPlugin` in
|
||||
a vim plugin. This conversion is necessary because neovim expects lua folders to be
|
||||
top-level while luarocks installs them in various subfolders by default.
|
||||
a vim plugin. This conversion is necessary because Neovim expects lua folders to be
|
||||
top-level while LuaRocks installs them in various subfolders by default.
|
||||
|
||||
For instance:
|
||||
```nix
|
||||
@@ -152,7 +152,7 @@ To enable all grammars packaged in nixpkgs, use `pkgs.vimPlugins.nvim-treesitter
|
||||
### Testing Neovim plugins {#testing-neovim-plugins}
|
||||
|
||||
#### neovimRequireCheck {#testing-neovim-plugins-neovim-require-check}
|
||||
`neovimRequireCheck` is a simple test which checks if Neovim can requires lua modules without errors. This is often enough to catch missing dependencies.
|
||||
`neovimRequireCheck` is a simple test which checks if Neovim can require lua modules without errors. This is often enough to catch missing dependencies.
|
||||
|
||||
It accepts a single string for a module, or a list of module strings to test.
|
||||
- `nvimRequireCheck = MODULE;`
|
||||
@@ -171,7 +171,7 @@ To only check a specific module, add it manually to the plugin definition [overr
|
||||
};
|
||||
}
|
||||
```
|
||||
Some plugins will have lua modules that require a user configuration to function properly or can contain optional lua modules that we dont want to test requiring.
|
||||
Some plugins will have lua modules that require a user configuration to function properly or can contain optional lua modules that we don't want to test by requiring.
|
||||
We can skip specific modules using `nvimSkipModules`. Similar to `nvimRequireCheck`, it accepts a list of strings.
|
||||
- `nvimSkipModules = [ MODULE1 MODULE2 ];`
|
||||
|
||||
|
||||
@@ -52,7 +52,7 @@ Here is a simple package example.
|
||||
|
||||
- It sets the optional `doCheck` attribute such that tests will be run with
|
||||
`dune runtest -p angstrom` after the build (`dune build -p angstrom`) is
|
||||
complete, but only if the Ocaml version is at at least `"4.05"`.
|
||||
complete, but only if the OCaml version is at at least `"4.05"`.
|
||||
|
||||
- It uses the package `ocaml-syntax-shims` as a build input, `alcotest` and
|
||||
`ppx_let` as check inputs (because they are needed to run the tests), and
|
||||
|
||||
@@ -16,7 +16,7 @@ All Octave add-on packages are available in two ways:
|
||||
Nixpkgs provides a function `buildOctavePackage`, a generic package builder function for any Octave package that complies with the Octave's current packaging format.
|
||||
|
||||
All Octave packages are defined in [pkgs/top-level/octave-packages.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/octave-packages.nix) rather than `pkgs/all-packages.nix`.
|
||||
Each package is defined in their own file in the [pkgs/development/octave-modules](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/octave-modules) directory.
|
||||
Each package is defined in its own file in the [pkgs/development/octave-modules](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/octave-modules) directory.
|
||||
Octave packages are made available through `all-packages.nix` through both the attribute `octavePackages` and `octave.pkgs`.
|
||||
You can test building an Octave package as follows:
|
||||
|
||||
@@ -54,7 +54,7 @@ The `buildOctavePackage` does several things to make sure things work properly.
|
||||
|
||||
1. Sets the environment variable `OCTAVE_HISTFILE` to `/dev/null` during package compilation so that the commands run through the Octave interpreter directly are not logged.
|
||||
2. Skips the configuration step, because the packages are stored as gzipped tarballs, which Octave itself handles directly.
|
||||
3. Change the hierarchy of the tarball so that only a single directory is at the top-most level of the tarball.
|
||||
3. Changes the hierarchy of the tarball so that only a single directory is at the top-most level of the tarball.
|
||||
4. Use Octave itself to run the `pkg build` command, which unzips the tarball, extracts the necessary files written in Octave, and compiles any code written in C++ or Fortran, and places the fully compiled artifact in `$out`.
|
||||
|
||||
`buildOctavePackage` is built on top of `stdenv` in a standard way, allowing most things to be customized.
|
||||
@@ -80,7 +80,7 @@ See [Symbolic](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/oct
|
||||
|
||||
By default, the `buildOctavePackage` function does _not_ install the requested package into Octave for use.
|
||||
The function will only build the requested package.
|
||||
This is due to Octave maintaining an text-based database about which packages are installed where.
|
||||
This is due to Octave maintaining a text-based database about which packages are installed where.
|
||||
To this end, when all the requested packages have been built, the Octave package and all its add-on packages are put together into an environment, similar to Python.
|
||||
|
||||
1. First, all the Octave binaries are wrapped with the environment variable `OCTAVE_SITE_INITFILE` set to a file in `$out`, which is required for Octave to be able to find the non-standard package database location.
|
||||
@@ -88,5 +88,5 @@ To this end, when all the requested packages have been built, the Octave package
|
||||
3. The path down to the default install location of Octave packages is recreated so that Nix-operated Octave can install the packages.
|
||||
4. Install the packages into the `$out` environment while writing package entries to the database file.
|
||||
This database file is unique for each different (according to Nix) environment invocation.
|
||||
5. Rewrite the Octave-wide startup file to read from the list of packages installed in that particular environment.
|
||||
5. Rewrites the Octave-wide startup file to read from the list of packages installed in that particular environment.
|
||||
6. Wrap any programs that are required by the Octave packages so that they work with all the paths defined within the environment.
|
||||
|
||||
@@ -201,7 +201,7 @@ Composer is not a package manager in the same sense as `Yum` or `Apt` are. Yes,
|
||||
it deals with "packages" or libraries, but it manages them on a per-project
|
||||
basis, installing them in a directory (e.g. `vendor`) inside your project. By
|
||||
default, it does not install anything globally. This idea is not new and
|
||||
Composer is strongly inspired by node's `npm` and ruby's `bundler`.
|
||||
Composer is strongly inspired by Node's `npm` and Ruby's `bundler`.
|
||||
|
||||
Currently, there is no other PHP tool that offers the same functionality as
|
||||
Composer. Consequently, incorporating a helper in Nix to facilitate building
|
||||
|
||||
@@ -9,7 +9,7 @@ Nixpkgs provides a couple of facilities for working with this tool.
|
||||
Packages should set `meta.pkgConfigModules` with the list of package config modules they provide.
|
||||
They should also use `testers.hasPkgConfigModules` to check that the final built package matches that list,
|
||||
and optionally check that the pkgconf modules' version metadata matches the derivation's.
|
||||
Additionally, the [`validatePkgConfig` setup hook](https://nixos.org/manual/nixpkgs/stable/#validatepkgconfig), will do extra checks on to-be-installed pkg-config modules.
|
||||
Additionally, the [`validatePkgConfig` setup hook](https://nixos.org/manual/nixpkgs/stable/#validatepkgconfig) will do extra checks on to-be-installed pkg-config modules.
|
||||
|
||||
A good example of all these things is miniz:
|
||||
|
||||
|
||||
@@ -565,8 +565,8 @@ are used in [`buildPythonPackage`](#buildpythonpackage-function).
|
||||
Several versions of the Python interpreter are available on Nix, as well as a
|
||||
high amount of packages. The attribute `python3` refers to the default
|
||||
interpreter, which is currently CPython 3.13. The attribute `python` refers to
|
||||
CPython 2.7 for backwards-compatibility. It is also possible to refer to
|
||||
specific versions, e.g. `python313` refers to CPython 3.13, and `pypy` refers to
|
||||
CPython 2.7 for backwards compatibility. It is also possible to refer to
|
||||
specific versions, e.g., `python313` refers to CPython 3.13, and `pypy` refers to
|
||||
the default PyPy interpreter.
|
||||
|
||||
Python is used a lot, and in different ways. This affects also how it is
|
||||
@@ -725,7 +725,7 @@ The dot product of [1 2] and [3 4] is: 11
|
||||
|
||||
If the dependencies are not available on the host where `foo.py` is executed, it
|
||||
will build or download them from a Nix binary cache prior to starting up, prior
|
||||
that it is executed on a machine with a multi-user nix installation.
|
||||
that it is executed on a machine with a multi-user Nix installation.
|
||||
|
||||
This provides a way to ship a self bootstrapping Python script, akin to a
|
||||
statically linked binary, where it can be run on any machine (provided nix is
|
||||
@@ -733,7 +733,7 @@ installed) without having to assume that `numpy` is installed globally on the
|
||||
system.
|
||||
|
||||
By default it is pulling the import checkout of Nixpkgs itself from our nix
|
||||
channel, which is nice as it cache aligns with our other package builds, but we
|
||||
channel, which is nice as it cache-aligns with our other package builds, but we
|
||||
can make it fully reproducible by pinning the `nixpkgs` import:
|
||||
|
||||
```python
|
||||
@@ -816,7 +816,7 @@ mkShell {
|
||||
|
||||
This will create a unified environment that has not just our Python interpreter
|
||||
and its Python dependencies, but also tools like `black` or `mypy` and libraries
|
||||
like `libffi` the `openssl` in scope. This is generic and can span any number of
|
||||
like `libffi` and `openssl` in scope. This is generic and can span any number of
|
||||
tools or languages across the Nixpkgs ecosystem.
|
||||
|
||||
##### Installing environments globally on the system {#installing-environments-globally-on-the-system}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Qt {#sec-language-qt}
|
||||
|
||||
Writing Nix expressions for Qt libraries and applications is largely similar as for other C++ software.
|
||||
Writing Nix expressions for Qt libraries and applications is largely similar to that for other C++ software.
|
||||
This section assumes some knowledge of the latter.
|
||||
|
||||
The major caveat with Qt applications is that Qt uses a plugin system to load additional modules at runtime.
|
||||
@@ -43,7 +43,7 @@ Applications should generally be built with upstream's preferred Qt version.
|
||||
|
||||
## Locating additional runtime dependencies {#qt-runtime-dependencies}
|
||||
|
||||
Add entries to `qtWrapperArgs` are to modify the wrappers created by
|
||||
Add entries to `qtWrapperArgs` to modify the wrappers created by
|
||||
`wrapQtAppsHook`:
|
||||
|
||||
```nix
|
||||
|
||||
@@ -263,7 +263,7 @@ $ bundle config set --local force_ruby_platform true
|
||||
|
||||
Now that you know how to get a working Ruby environment with Nix, it's time to go forward and start actually developing with Ruby. We will first have a look at how Ruby gems are packaged on Nix. Then, we will look at how you can use development mode with your code.
|
||||
|
||||
All gems in the standard set are automatically generated from a single `Gemfile`. The dependency resolution is done with `bundler` and makes it more likely that all gems are compatible to each other.
|
||||
All gems in the standard set are automatically generated from a single `Gemfile`. The dependency resolution is done with `bundler` and makes it more likely that all gems are compatible with each other.
|
||||
|
||||
In order to add a new gem to nixpkgs, you can put it into the `/pkgs/development/ruby-modules/with-packages/Gemfile` and run `./maintainers/scripts/update-ruby-packages`.
|
||||
|
||||
@@ -275,7 +275,7 @@ NIX_PATH=nixpkgs=$PWD nix-shell -p "ruby.withPackages (ps: with ps; [ name-of-yo
|
||||
|
||||
### Packaging applications {#packaging-applications}
|
||||
|
||||
A common task is to add a ruby executable to nixpkgs, popular examples would be `chef`, `jekyll`, or `sass`. A good way to do that is to use the `bundlerApp` function, that allows you to make a package that only exposes the listed executables, otherwise the package may cause conflicts through common paths like `bin/rake` or `bin/bundler` that aren't meant to be used.
|
||||
A common task is to add a Ruby executable to Nixpkgs; popular examples would be `chef`, `jekyll`, or `sass`. A good way to do that is to use the `bundlerApp` function, that allows you to make a package that only exposes the listed executables. Otherwise, the package may cause conflicts through common paths like `bin/rake` or `bin/bundler` that aren't meant to be used.
|
||||
|
||||
The absolute easiest way to do that is to write a `Gemfile` along these lines:
|
||||
|
||||
@@ -303,7 +303,7 @@ All that's left to do is to generate the corresponding `Gemfile.lock` and `gemse
|
||||
|
||||
#### Packaging executables that require wrapping {#packaging-executables-that-require-wrapping}
|
||||
|
||||
Sometimes your app will depend on other executables at runtime, and tries to find it through the `PATH` environment variable.
|
||||
Sometimes your app will depend on other executables at runtime and try to find them through the `PATH` environment variable.
|
||||
|
||||
In this case, you can provide a `postBuild` hook to `bundlerApp` that wraps the gem in another script that prefixes the `PATH`.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Rust {#rust}
|
||||
|
||||
To install the rust compiler and cargo put
|
||||
To install the Rust compiler and cargo, put
|
||||
|
||||
```nix
|
||||
{
|
||||
@@ -14,7 +14,7 @@ To install the rust compiler and cargo put
|
||||
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),
|
||||
use either `rustup` from Nixpkgs (which will manage the rust installation in your home directory),
|
||||
or use [community maintained Rust toolchains](#using-community-maintained-rust-toolchains).
|
||||
|
||||
## `buildRustPackage`: Compiling Rust applications with Cargo {#compiling-rust-applications-with-cargo}
|
||||
@@ -65,10 +65,10 @@ hash using `nix-hash --to-sri --type sha256 "<original sha256>"`.
|
||||
{ cargoHash = "sha256-l1vL2ZdtDRxSGvP0X/l3nMw8+6WF67KPutJEzUROjg8="; }
|
||||
```
|
||||
|
||||
If this method does not work, you can resort to copying the `Cargo.lock` file into nixpkgs
|
||||
If this method does not work, you can resort to copying the `Cargo.lock` file into Nixpkgs
|
||||
and importing it as described in the [next section](#importing-a-cargo.lock-file).
|
||||
|
||||
Both types of hashes are permitted when contributing to nixpkgs. The
|
||||
Both types of hashes are permitted when contributing to Nixpkgs. The
|
||||
Cargo hash is obtained by inserting a fake checksum into the
|
||||
expression and building the package once. The correct checksum can
|
||||
then be taken from the failed build. A fake hash can be used for
|
||||
@@ -249,7 +249,7 @@ rustPlatform.buildRustPackage {
|
||||
### Cross compilation {#cross-compilation}
|
||||
|
||||
By default, Rust packages are compiled for the host platform, just like any
|
||||
other package is. The `--target` passed to rust tools is computed from this.
|
||||
other package is. The `--target` passed to Rust tools is computed from this.
|
||||
By default, it takes the `stdenv.hostPlatform.config` and replaces components
|
||||
where they are known to differ. But there are ways to customize the argument:
|
||||
|
||||
@@ -417,7 +417,7 @@ Otherwise, some steps may fail because of the modified directory structure of `t
|
||||
### Building a crate with an absent or out-of-date Cargo.lock file {#building-a-crate-with-an-absent-or-out-of-date-cargo.lock-file}
|
||||
|
||||
`buildRustPackage` needs a `Cargo.lock` file to get all dependencies in the
|
||||
source code in a reproducible way. If it is missing or out-of-date one can use
|
||||
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
|
||||
@@ -907,7 +907,7 @@ $ cargo test
|
||||
## Using community maintained Rust toolchains {#using-community-maintained-rust-toolchains}
|
||||
|
||||
::: {.note}
|
||||
The following projects cannot be used within Nixpkgs since [Import From Derivation](https://nixos.org/manual/nix/unstable/language/import-from-derivation) (IFD) is disallowed in Nixpkgs.
|
||||
The following projects cannot be used within Nixpkgs, since [Import From Derivation](https://nixos.org/manual/nix/unstable/language/import-from-derivation) (IFD) is disallowed in Nixpkgs.
|
||||
To package things that require Rust nightly, `RUSTC_BOOTSTRAP = true;` can sometimes be used as a hack.
|
||||
:::
|
||||
|
||||
@@ -920,7 +920,7 @@ Despite their names, both projects provides a similar set of packages and overla
|
||||
Oxalica's overlay allows you to select a particular Rust version without you providing a hash or a flake input,
|
||||
but comes with a larger git repository than fenix.
|
||||
|
||||
Fenix also provides rust-analyzer nightly in addition to the Rust toolchains.
|
||||
Fenix also provides `rust-analyzer` nightly in addition to the Rust toolchains.
|
||||
|
||||
Both oxalica's overlay and fenix better integrate with nix and cache optimizations.
|
||||
Because of this and ergonomics, either of those community projects
|
||||
|
||||
@@ -11,7 +11,7 @@ itself is at the top level as `akku`. The packages could be used
|
||||
in a derivation's `buildInputs`, work inside of `nix-shell`, and
|
||||
are tested using [Chez](https://www.scheme.com/) &
|
||||
[Chibi](https://synthcode.com/wiki/chibi-scheme)
|
||||
Scheme during build time.
|
||||
Scheme at build time.
|
||||
|
||||
Including a package as a build input is done in the typical Nix fashion.
|
||||
For example, to include
|
||||
|
||||
@@ -34,13 +34,13 @@ look for the following directories:
|
||||
(Where `linux` and `x86_64` are from lowercase `uname -sm`.)
|
||||
- For convenience, Nixpkgs also adds `lib/swift` to the search path.
|
||||
This can save a bit of work packaging Swift modules, because many Nix builds
|
||||
will produce output for just one target any way.
|
||||
will produce output for just one target anyway.
|
||||
|
||||
## Core libraries {#ssec-swift-core-libraries}
|
||||
|
||||
In addition to the standard library, the Swift toolchain contains some
|
||||
additional 'core libraries' that, on Apple platforms, are normally distributed
|
||||
as part of the OS or Xcode. These are packaged separately in Nixpkgs, and can
|
||||
as part of the OS or Xcode. These are packaged separately in Nixpkgs and can
|
||||
be found (for use in `buildInputs`) as:
|
||||
|
||||
- `swiftPackages.Dispatch`
|
||||
@@ -189,7 +189,7 @@ with a writable copy:
|
||||
|
||||
The `swift` package has a separate `lib` output containing just the Swift
|
||||
standard library, to prevent Swift applications needing a dependency on the
|
||||
full Swift compiler at run-time. Linking with the Nixpkgs Swift toolchain
|
||||
full Swift compiler at runtime. Linking with the Nixpkgs Swift toolchain
|
||||
already ensures binaries correctly reference the `lib` output.
|
||||
|
||||
Sometimes, Swift is used only to compile part of a mixed codebase, and the
|
||||
|
||||
@@ -48,7 +48,7 @@ Release 23.11 ships with a new interface that will eventually replace `texlive.c
|
||||
```
|
||||
This can be applied before or after calling `withPackages`.
|
||||
|
||||
The function currently support the parameters `withDocs`, `withSources`, and `requireTeXPackages`.
|
||||
The function currently supports the parameters `withDocs`, `withSources`, and `requireTeXPackages`.
|
||||
|
||||
## User's guide {#sec-language-texlive-user-guide}
|
||||
|
||||
@@ -89,7 +89,7 @@ Release 23.11 ships with a new interface that will eventually replace `texlive.c
|
||||
nix-repl> texlive.collection-[TAB]
|
||||
```
|
||||
|
||||
- Note that the wrapper assumes that the result has a chance to be useful. For example, the core executables should be present, as well as some core data files. The supported way of ensuring this is by including some scheme, for example `scheme-basic`, into the combination.
|
||||
- Note that the wrapper assumes that the result has a chance to be useful. For example, the core executables should be present, as well as some core data files. The supported way of ensuring this is by including some scheme, for example, `scheme-basic`, into the combination.
|
||||
|
||||
- TeX Live packages are also available under `texlive.pkgs` as derivations with outputs `out`, `tex`, `texdoc`, `texsource`, `tlpkg`, `man`, `info`. They cannot be installed outside of `texlive.combine` but are available for other uses. To repackage a font, for instance, use
|
||||
|
||||
|
||||
@@ -192,7 +192,7 @@ If you want to update only certain plugins, you can specify them after the `upda
|
||||
nix-shell -p vimPluginsUpdater --run 'vim-plugins-updater update "nvim-treesitter" "LazyVim"'
|
||||
```
|
||||
|
||||
## How to maintain an out-of-tree overlay of vim plugins ? {#vim-out-of-tree-overlays}
|
||||
## How to maintain an out-of-tree overlay of vim plugins? {#vim-out-of-tree-overlays}
|
||||
|
||||
You can use the updater script to generate basic packages out of a custom vim
|
||||
plugin list:
|
||||
|
||||
Reference in New Issue
Block a user