Merge branch 'master' into nextcloud-secrets
This commit is contained in:
stuebinm
GitHub
commit
c3e03d1199
@ -55,6 +55,11 @@ trim_trailing_whitespace = unset
|
||||
[*.lock]
|
||||
indent_size = unset
|
||||
|
||||
# trailing whitespace is an actual syntax element of classic Markdown/
|
||||
# CommonMark to enforce a line break
|
||||
[*.md]
|
||||
trim_trailing_whitespace = unset
|
||||
|
||||
[eggs.nix]
|
||||
trim_trailing_whitespace = unset
|
||||
|
||||
|
||||
@ -30,3 +30,6 @@
|
||||
|
||||
# nixos: fix module paths in rename.nix
|
||||
d08ede042b74b8199dc748323768227b88efcf7c
|
||||
|
||||
# fix indentation in mk-python-derivation.nix
|
||||
d1c1a0c656ccd8bd3b25d3c4287f2d075faf3cf3
|
||||
|
||||
22
.github/CODEOWNERS
vendored
22
.github/CODEOWNERS
vendored
@ -98,13 +98,13 @@
|
||||
/pkgs/development/interpreters/python/hooks @FRidh @jonringer
|
||||
|
||||
# Haskell
|
||||
/doc/languages-frameworks/haskell.section.md @cdepillabout @sternenseemann @maralorn @expipiplus1
|
||||
/maintainers/scripts/haskell @cdepillabout @sternenseemann @maralorn @expipiplus1
|
||||
/pkgs/development/compilers/ghc @cdepillabout @sternenseemann @maralorn @expipiplus1
|
||||
/pkgs/development/haskell-modules @cdepillabout @sternenseemann @maralorn @expipiplus1
|
||||
/pkgs/test/haskell @cdepillabout @sternenseemann @maralorn @expipiplus1
|
||||
/pkgs/top-level/release-haskell.nix @cdepillabout @sternenseemann @maralorn @expipiplus1
|
||||
/pkgs/top-level/haskell-packages.nix @cdepillabout @sternenseemann @maralorn @expipiplus1
|
||||
/doc/languages-frameworks/haskell.section.md @cdepillabout @sternenseemann @maralorn
|
||||
/maintainers/scripts/haskell @cdepillabout @sternenseemann @maralorn
|
||||
/pkgs/development/compilers/ghc @cdepillabout @sternenseemann @maralorn
|
||||
/pkgs/development/haskell-modules @cdepillabout @sternenseemann @maralorn
|
||||
/pkgs/test/haskell @cdepillabout @sternenseemann @maralorn
|
||||
/pkgs/top-level/release-haskell.nix @cdepillabout @sternenseemann @maralorn
|
||||
/pkgs/top-level/haskell-packages.nix @cdepillabout @sternenseemann @maralorn
|
||||
|
||||
# Perl
|
||||
/pkgs/development/interpreters/perl @stigtsp @zakame
|
||||
@ -192,8 +192,8 @@
|
||||
/nixos/tests/knot.nix @mweinelt
|
||||
|
||||
# Dhall
|
||||
/pkgs/development/dhall-modules @Gabriel439 @Profpatsch @ehmry
|
||||
/pkgs/development/interpreters/dhall @Gabriel439 @Profpatsch @ehmry
|
||||
/pkgs/development/dhall-modules @Gabriella439 @Profpatsch @ehmry
|
||||
/pkgs/development/interpreters/dhall @Gabriella439 @Profpatsch @ehmry
|
||||
|
||||
# Idris
|
||||
/pkgs/development/idris-modules @Infinisil
|
||||
@ -285,3 +285,7 @@
|
||||
/nixos/modules/services/misc/matrix-conduit.nix @piegamesde
|
||||
/nixos/tests/matrix-appservice-irc.nix @piegamesde
|
||||
/nixos/tests/matrix-conduit.nix @piegamesde
|
||||
|
||||
# Dotnet
|
||||
/pkgs/build-support/dotnet @IvarWithoutBones
|
||||
/pkgs/development/compilers/dotnet @IvarWithoutBones
|
||||
|
||||
34
.github/ISSUE_TEMPLATE/build_failure.md
vendored
Normal file
34
.github/ISSUE_TEMPLATE/build_failure.md
vendored
Normal file
@ -0,0 +1,34 @@
|
||||
---
|
||||
name: Build failure
|
||||
about: Create a report to help us improve
|
||||
title: ''
|
||||
labels: '0.kind: build failure'
|
||||
assignees: ''
|
||||
|
||||
---
|
||||
|
||||
### Steps To Reproduce
|
||||
Steps to reproduce the behavior:
|
||||
1. build *X*
|
||||
|
||||
### Build log
|
||||
```
|
||||
log here if short otherwise a link to a gist
|
||||
```
|
||||
|
||||
### Additional context
|
||||
Add any other context about the problem here.
|
||||
|
||||
### Notify maintainers
|
||||
<!--
|
||||
Please @ people who are in the `meta.maintainers` list of the offending package or module.
|
||||
If in doubt, check `git blame` for whoever last touched something.
|
||||
-->
|
||||
|
||||
### Metadata
|
||||
Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the result.
|
||||
|
||||
```console
|
||||
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
|
||||
output here
|
||||
```
|
||||
2
.github/PULL_REQUEST_TEMPLATE.md
vendored
2
.github/PULL_REQUEST_TEMPLATE.md
vendored
@ -22,7 +22,7 @@ For new packages please briefly describe the package or provide a link to its ho
|
||||
- made sure NixOS tests are [linked](https://nixos.org/manual/nixpkgs/unstable/#ssec-nixos-tests-linking) to the relevant packages
|
||||
- [ ] Tested compilation of all packages that depend on this change using `nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"`. Note: all changes have to be committed, also see [nixpkgs-review usage](https://github.com/Mic92/nixpkgs-review#usage)
|
||||
- [ ] Tested basic functionality of all binary files (usually in `./result/bin/`)
|
||||
- [22.05 Release Notes (or backporting 21.11 Release notes)](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#generating-2205-release-notes)
|
||||
- [22.11 Release Notes (or backporting 22.05 Release notes)](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#generating-2211-release-notes)
|
||||
- [ ] (Package updates) Added a release notes entry if the change is major or breaking
|
||||
- [ ] (Module updates) Added a release notes entry if the change is significant
|
||||
- [ ] (Module addition) Added a release notes entry if adding a new NixOS module
|
||||
|
||||
1
.github/STALE-BOT.md
vendored
1
.github/STALE-BOT.md
vendored
@ -1,6 +1,7 @@
|
||||
# Stale bot information
|
||||
|
||||
- Thanks for your contribution!
|
||||
- Our stale bot will never close an issue or PR.
|
||||
- To remove the stale label, just leave a new comment.
|
||||
- _How to find the right people to ping?_ → [`git blame`](https://git-scm.com/docs/git-blame) to the rescue! (or GitHub's history and blame buttons.)
|
||||
- You can always ask for help on [our Discourse Forum](https://discourse.nixos.org/), [our Matrix room](https://matrix.to/#/#nix:nixos.org), or on the [#nixos IRC channel](https://web.libera.chat/#nixos).
|
||||
|
||||
3
.github/stale.yml
vendored
3
.github/stale.yml
vendored
@ -5,6 +5,5 @@ exemptLabels:
|
||||
- "1.severity: security"
|
||||
- "2.status: never-stale"
|
||||
staleLabel: "2.status: stale"
|
||||
markComment: |
|
||||
I marked this as stale due to inactivity. → [More info](https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md)
|
||||
markComment: false
|
||||
closeComment: false
|
||||
|
||||
8
.github/workflows/periodic-merge-24h.yml
vendored
8
.github/workflows/periodic-merge-24h.yml
vendored
@ -28,14 +28,14 @@ jobs:
|
||||
pairs:
|
||||
- from: master
|
||||
into: haskell-updates
|
||||
- from: release-21.05
|
||||
into: staging-next-21.05
|
||||
- from: staging-next-21.05
|
||||
into: staging-21.05
|
||||
- from: release-21.11
|
||||
into: staging-next-21.11
|
||||
- from: staging-next-21.11
|
||||
into: staging-21.11
|
||||
- from: release-22.05
|
||||
into: staging-next-22.05
|
||||
- from: staging-next-22.05
|
||||
into: staging-22.05
|
||||
name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
||||
11
.github/workflows/update-terraform-providers.yml
vendored
11
.github/workflows/update-terraform-providers.yml
vendored
@ -25,14 +25,15 @@ jobs:
|
||||
git commit -m "${{ steps.setup.outputs.title }}" providers.json
|
||||
popd
|
||||
- name: create PR
|
||||
uses: peter-evans/create-pull-request@v3
|
||||
uses: peter-evans/create-pull-request@v4
|
||||
with:
|
||||
body: |
|
||||
Automatic update of terraform providers.
|
||||
Automatic update by [update-terraform-providers](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/update-terraform-providers.yml) action.
|
||||
|
||||
Created by [update-terraform-providers](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/update-terraform-providers.yml) action.
|
||||
|
||||
Check that all providers build with `@ofborg build terraform-full`
|
||||
Check that all providers build with:
|
||||
```
|
||||
@ofborg build terraform-full
|
||||
```
|
||||
branch: terraform-providers-update
|
||||
delete-branch: false
|
||||
labels: "2.status: work-in-progress"
|
||||
|
||||
4
.gitignore
vendored
4
.gitignore
vendored
@ -5,13 +5,13 @@
|
||||
.idea/
|
||||
.vscode/
|
||||
outputs/
|
||||
result
|
||||
result-*
|
||||
source/
|
||||
/doc/NEWS.html
|
||||
/doc/NEWS.txt
|
||||
/doc/manual.html
|
||||
/doc/manual.pdf
|
||||
/result
|
||||
/source/
|
||||
.version-suffix
|
||||
|
||||
.DS_Store
|
||||
|
||||
@ -97,11 +97,17 @@ git push origin $(git branch --show-current) --force-with-lease
|
||||
|
||||
Follow these steps to backport a change into a release branch in compliance with the [commit policy](https://nixos.org/nixpkgs/manual/#submitting-changes-stable-release-branches).
|
||||
|
||||
You can add a label such as `backport release-22.05` to a PR, so that merging it will
|
||||
automatically create a backport (via [a GitHub Action](.github/workflows/backport.yml)).
|
||||
This also works for PR's that have already been merged, and might take a couple of minutes to trigger.
|
||||
|
||||
You can also create the backport manually:
|
||||
|
||||
1. Take note of the commits in which the change was introduced into `master` branch.
|
||||
2. Check out the target _release branch_, e.g. `release-21.11`. Do not use a _channel branch_ like `nixos-21.11` or `nixpkgs-21.11-darwin`.
|
||||
2. Check out the target _release branch_, e.g. `release-22.05`. Do not use a _channel branch_ like `nixos-22.05` or `nixpkgs-22.05-darwin`.
|
||||
3. Create a branch for your change, e.g. `git checkout -b backport`.
|
||||
4. When the reason to backport is not obvious from the original commit message, use `git cherry-pick -xe <original commit>` and add a reason. Otherwise use `git cherry-pick -x <original commit>`. That's fine for minor version updates that only include security and bug fixes, commits that fixes an otherwise broken package or similar. Please also ensure the commits exists on the master branch; in the case of squashed or rebased merges, the commit hash will change and the new commits can be found in the merge message at the bottom of the master pull request.
|
||||
5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-21.11`) as the target branch of the pull request, and link to the pull request in which the original change was comitted to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[21.11]`.
|
||||
5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-22.05`) as the target branch of the pull request, and link to the pull request in which the original change was comitted to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[22.05]`.
|
||||
6. When the backport pull request is merged and you have the necessary privileges you can also replace the label `9.needs: port to stable` with `8.has: port to stable` on the original pull request. This way maintainers can keep track of missing backports easier.
|
||||
|
||||
## Criteria for Backporting changes
|
||||
@ -113,17 +119,15 @@ Anything that does not cause user or downstream dependency regressions can be ba
|
||||
- Services which require a client to be up-to-date regardless. (E.g. `spotify`, `steam`, or `discord`)
|
||||
- Security critical applications (E.g. `firefox`)
|
||||
|
||||
## Generating 22.05 Release Notes
|
||||
|
||||
(This section also applies to backporting 21.11 release notes: substitute "rl-2205" for "rl-2111".)
|
||||
## Generating 22.11 Release Notes
|
||||
|
||||
Documentation in nixpkgs is transitioning to a markdown-centric workflow. Release notes now require a translation step to convert from markdown to a compatible docbook document.
|
||||
|
||||
Steps for updating 22.05 Release notes:
|
||||
Steps for updating 22.11 Release notes:
|
||||
|
||||
1. Edit `nixos/doc/manual/release-notes/rl-2205.section.md` with the desired changes
|
||||
2. Run `./nixos/doc/manual/md-to-db.sh` to render `nixos/doc/manual/from_md/release-notes/rl-2205.section.xml`
|
||||
3. Include changes to `rl-2205.section.md` and `rl-2205.section.xml` in the same commit.
|
||||
1. Edit `nixos/doc/manual/release-notes/rl-2211.section.md` with the desired changes
|
||||
2. Run `./nixos/doc/manual/md-to-db.sh` to render `nixos/doc/manual/from_md/release-notes/rl-2211.section.xml`
|
||||
3. Include changes to `rl-2211.section.md` and `rl-2211.section.xml` in the same commit.
|
||||
|
||||
## Reviewing contributions
|
||||
|
||||
|
||||
@ -51,9 +51,9 @@ Nixpkgs and NixOS are built and tested by our continuous integration
|
||||
system, [Hydra](https://hydra.nixos.org/).
|
||||
|
||||
* [Continuous package builds for unstable/master](https://hydra.nixos.org/jobset/nixos/trunk-combined)
|
||||
* [Continuous package builds for the NixOS 21.11 release](https://hydra.nixos.org/jobset/nixos/release-21.11)
|
||||
* [Continuous package builds for the NixOS 22.05 release](https://hydra.nixos.org/jobset/nixos/release-22.05)
|
||||
* [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
|
||||
* [Tests for the NixOS 21.11 release](https://hydra.nixos.org/job/nixos/release-21.11/tested#tabs-constituents)
|
||||
* [Tests for the NixOS 22.05 release](https://hydra.nixos.org/job/nixos/release-22.05/tested#tabs-constituents)
|
||||
|
||||
Artifacts successfully built with Hydra are published to cache at
|
||||
https://cache.nixos.org/. When successful build and test criteria are
|
||||
|
||||
@ -27,6 +27,10 @@ function Code(elem)
|
||||
content = '<refentrytitle>' .. title .. '</refentrytitle>' .. (volnum ~= nil and ('<manvolnum>' .. volnum .. '</manvolnum>') or '')
|
||||
elseif elem.attributes['role'] == 'file' then
|
||||
tag = 'filename'
|
||||
elseif elem.attributes['role'] == 'command' then
|
||||
tag = 'command'
|
||||
elseif elem.attributes['role'] == 'option' then
|
||||
tag = 'option'
|
||||
end
|
||||
|
||||
if tag ~= nil then
|
||||
|
||||
@ -10,7 +10,7 @@ For those who develop and maintain fetchers, a similar problem arises with chang
|
||||
|
||||
## `fetchurl` and `fetchzip` {#fetchurl}
|
||||
|
||||
Two basic fetchers are `fetchurl` and `fetchzip`. Both of these have two required arguments, a URL and a hash. The hash is typically `sha256`, although many more hash algorithms are supported. Nixpkgs contributors are currently recommended to use `sha256`. This hash will be used by Nix to identify your source. A typical usage of fetchurl is provided below.
|
||||
Two basic fetchers are `fetchurl` and `fetchzip`. Both of these have two required arguments, a URL and a hash. The hash is typically `sha256`, although many more hash algorithms are supported. Nixpkgs contributors are currently recommended to use `sha256`. This hash will be used by Nix to identify your source. A typical usage of `fetchurl` is provided below.
|
||||
|
||||
```nix
|
||||
{ stdenv, fetchurl }:
|
||||
@ -24,9 +24,21 @@ stdenv.mkDerivation {
|
||||
}
|
||||
```
|
||||
|
||||
The main difference between `fetchurl` and `fetchzip` is in how they store the contents. `fetchurl` will store the unaltered contents of the URL within the Nix store. `fetchzip` on the other hand will decompress the archive for you, making files and directories directly accessible in the future. `fetchzip` can only be used with archives. Despite the name, `fetchzip` is not limited to .zip files and can also be used with any tarball.
|
||||
The main difference between `fetchurl` and `fetchzip` is in how they store the contents. `fetchurl` will store the unaltered contents of the URL within the Nix store. `fetchzip` on the other hand, will decompress the archive for you, making files and directories directly accessible in the future. `fetchzip` can only be used with archives. Despite the name, `fetchzip` is not limited to .zip files and can also be used with any tarball.
|
||||
|
||||
## `fetchpatch` {#fetchpatch}
|
||||
|
||||
`fetchpatch` works very similarly to `fetchurl` with the same arguments expected. It expects patch files as a source and performs normalization on them before computing the checksum. For example, it will remove comments or other unstable parts that are sometimes added by version control systems and can change over time.
|
||||
|
||||
- `relative`: Similar to using `git-diff`'s `--relative` flag, only keep changes inside the specified directory, making paths relative to it.
|
||||
- `stripLen`: Remove the first `stripLen` components of pathnames in the patch.
|
||||
- `extraPrefix`: Prefix pathnames by this string.
|
||||
- `excludes`: Exclude files matching these patterns (applies after the above arguments).
|
||||
- `includes`: Include only files matching these patterns (applies after the above arguments).
|
||||
- `revert`: Revert the patch.
|
||||
|
||||
Note that because the checksum is computed after applying these effects, using or modifying these arguments will have no effect unless the `sha256` argument is changed as well.
|
||||
|
||||
`fetchpatch` works very similarly to `fetchurl` with the same arguments expected. It expects patch files as a source and performs normalization on them before computing the checksum. For example it will remove comments or other unstable parts that are sometimes added by version control systems and can change over time.
|
||||
|
||||
Most other fetchers return a directory rather than a single file.
|
||||
|
||||
@ -38,9 +50,9 @@ Used with Subversion. Expects `url` to a Subversion directory, `rev`, and `sha25
|
||||
|
||||
Used with Git. Expects `url` to a Git repo, `rev`, and `sha256`. `rev` in this case can be full the git commit id (SHA1 hash) or a tag name like `refs/tags/v1.0`.
|
||||
|
||||
Additionally the following optional arguments can be given: `fetchSubmodules = true` makes `fetchgit` also fetch the submodules of a repository. If `deepClone` is set to true, the entire repository is cloned as opposing to just creating a shallow clone. `deepClone = true` also implies `leaveDotGit = true` which means that the `.git` directory of the clone won't be removed after checkout.
|
||||
Additionally, the following optional arguments can be given: `fetchSubmodules = true` makes `fetchgit` also fetch the submodules of a repository. If `deepClone` is set to true, the entire repository is cloned as opposing to just creating a shallow clone. `deepClone = true` also implies `leaveDotGit = true` which means that the `.git` directory of the clone won't be removed after checkout.
|
||||
|
||||
If only parts of the repository are needed, `sparseCheckout` can be used. This will prevent git from fetching unnecessary blobs from server, see [git sparse-checkout](https://git-scm.com/docs/git-sparse-checkout) and [git clone --filter](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---filterltfilter-specgt) for more infomation:
|
||||
If only parts of the repository are needed, `sparseCheckout` can be used. This will prevent git from fetching unnecessary blobs from server, see [git sparse-checkout](https://git-scm.com/docs/git-sparse-checkout) and [git clone --filter](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---filterltfilter-specgt) for more information:
|
||||
|
||||
```nix
|
||||
{ stdenv, fetchgit }:
|
||||
@ -78,17 +90,17 @@ A number of fetcher functions wrap part of `fetchurl` and `fetchzip`. They are m
|
||||
|
||||
## `fetchFromGitHub` {#fetchfromgithub}
|
||||
|
||||
`fetchFromGitHub` expects four arguments. `owner` is a string corresponding to the GitHub user or organization that controls this repository. `repo` corresponds to the name of the software repository. These are located at the top of every GitHub HTML page as `owner`/`repo`. `rev` corresponds to the Git commit hash or tag (e.g `v1.0`) that will be downloaded from Git. Finally, `sha256` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available but `sha256` is currently preferred.
|
||||
`fetchFromGitHub` expects four arguments. `owner` is a string corresponding to the GitHub user or organization that controls this repository. `repo` corresponds to the name of the software repository. These are located at the top of every GitHub HTML page as `owner`/`repo`. `rev` corresponds to the Git commit hash or tag (e.g `v1.0`) that will be downloaded from Git. Finally, `sha256` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available, but `sha256` is currently preferred.
|
||||
|
||||
`fetchFromGitHub` uses `fetchzip` to download the source archive generated by GitHub for the specified revision. If `leaveDotGit`, `deepClone` or `fetchSubmodules` are set to `true`, `fetchFromGitHub` will use `fetchgit` instead. Refer to its section for documentation of these options.
|
||||
|
||||
## `fetchFromGitLab` {#fetchfromgitlab}
|
||||
|
||||
This is used with GitLab repositories. The arguments expected are very similar to fetchFromGitHub above.
|
||||
This is used with GitLab repositories. The arguments expected are very similar to `fetchFromGitHub` above.
|
||||
|
||||
## `fetchFromGitiles` {#fetchfromgitiles}
|
||||
|
||||
This is used with Gitiles repositories. The arguments expected are similar to fetchgit.
|
||||
This is used with Gitiles repositories. The arguments expected are similar to `fetchgit`.
|
||||
|
||||
## `fetchFromBitbucket` {#fetchfrombitbucket}
|
||||
|
||||
@ -96,11 +108,11 @@ This is used with BitBucket repositories. The arguments expected are very simila
|
||||
|
||||
## `fetchFromSavannah` {#fetchfromsavannah}
|
||||
|
||||
This is used with Savannah repositories. The arguments expected are very similar to fetchFromGitHub above.
|
||||
This is used with Savannah repositories. The arguments expected are very similar to `fetchFromGitHub` above.
|
||||
|
||||
## `fetchFromRepoOrCz` {#fetchfromrepoorcz}
|
||||
|
||||
This is used with repo.or.cz repositories. The arguments expected are very similar to fetchFromGitHub above.
|
||||
This is used with repo.or.cz repositories. The arguments expected are very similar to `fetchFromGitHub` above.
|
||||
|
||||
## `fetchFromSourcehut` {#fetchfromsourcehut}
|
||||
|
||||
@ -111,4 +123,4 @@ or "hg"), `domain` and `fetchSubmodules`.
|
||||
|
||||
If `fetchSubmodules` is `true`, `fetchFromSourcehut` uses `fetchgit`
|
||||
or `fetchhg` with `fetchSubmodules` or `fetchSubrepos` set to `true`,
|
||||
respectively. Otherwise the fetcher uses `fetchzip`.
|
||||
respectively. Otherwise, the fetcher uses `fetchzip`.
|
||||
|
||||
@ -58,7 +58,7 @@ After the new layer has been created, its closure (to which `contents`, `config`
|
||||
|
||||
At the end of the process, only one new single layer will be produced and added to the resulting image.
|
||||
|
||||
The resulting repository will only list the single image `image/tag`. In the case of [the `buildImage` example](#ex-dockerTools-buildImage) it would be `redis/latest`.
|
||||
The resulting repository will only list the single image `image/tag`. In the case of [the `buildImage` example](#ex-dockerTools-buildImage), it would be `redis/latest`.
|
||||
|
||||
It is possible to inspect the arguments with which an image was built using its `buildArgs` attribute.
|
||||
|
||||
@ -87,7 +87,7 @@ pkgs.dockerTools.buildImage {
|
||||
}
|
||||
```
|
||||
|
||||
and now the Docker CLI will display a reasonable date and sort the images as expected:
|
||||
Now the Docker CLI will display a reasonable date and sort the images as expected:
|
||||
|
||||
```ShellSession
|
||||
$ docker images
|
||||
@ -95,7 +95,7 @@ REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
hello latest de2bf4786de6 About a minute ago 25.2MB
|
||||
```
|
||||
|
||||
however, the produced images will not be binary reproducible.
|
||||
However, the produced images will not be binary reproducible.
|
||||
|
||||
## buildLayeredImage {#ssec-pkgs-dockerTools-buildLayeredImage}
|
||||
|
||||
@ -119,13 +119,13 @@ Create a Docker image with many of the store paths being on their own layer to i
|
||||
|
||||
`contents` _optional_
|
||||
|
||||
: Top level paths in the container. Either a single derivation, or a list of derivations.
|
||||
: Top-level paths in the container. Either a single derivation, or a list of derivations.
|
||||
|
||||
*Default:* `[]`
|
||||
|
||||
`config` _optional_
|
||||
|
||||
: Run-time configuration of the container. A full list of the options are available at in the [ Docker Image Specification v1.2.0 ](https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions).
|
||||
: Run-time configuration of the container. A full list of the options are available at in the [Docker Image Specification v1.2.0](https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions).
|
||||
|
||||
*Default:* `{}`
|
||||
|
||||
@ -195,9 +195,9 @@ pkgs.dockerTools.buildLayeredImage {
|
||||
|
||||
Increasing the `maxLayers` increases the number of layers which have a chance to be shared between different images.
|
||||
|
||||
Modern Docker installations support up to 128 layers, however older versions support as few as 42.
|
||||
Modern Docker installations support up to 128 layers, but older versions support as few as 42.
|
||||
|
||||
If the produced image will not be extended by other Docker builds, it is safe to set `maxLayers` to `128`. However it will be impossible to extend the image further.
|
||||
If the produced image will not be extended by other Docker builds, it is safe to set `maxLayers` to `128`. However, it will be impossible to extend the image further.
|
||||
|
||||
The first (`maxLayers-2`) most "popular" paths will have their own individual layers, then layer \#`maxLayers-1` will contain all the remaining "unpopular" paths, and finally layer \#`maxLayers` will contain the Image configuration.
|
||||
|
||||
@ -213,7 +213,7 @@ The image produced by running the output script can be piped directly into `dock
|
||||
$(nix-build) | docker load
|
||||
```
|
||||
|
||||
Alternatively, the image be piped via `gzip` into `skopeo`, e.g. to copy it into a registry:
|
||||
Alternatively, the image be piped via `gzip` into `skopeo`, e.g., to copy it into a registry:
|
||||
|
||||
```ShellSession
|
||||
$(nix-build) | gzip --fast | skopeo copy docker-archive:/dev/stdin docker://some_docker_registry/myimage:tag
|
||||
@ -302,7 +302,7 @@ buildImage {
|
||||
|
||||
runAsRoot = ''
|
||||
#!${pkgs.runtimeShell}
|
||||
${shadowSetup}
|
||||
${pkgs.dockerTools.shadowSetup}
|
||||
groupadd -r redis
|
||||
useradd -r -g redis redis
|
||||
mkdir /data
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
# pkgs.ociTools {#sec-pkgs-ociTools}
|
||||
|
||||
`pkgs.ociTools` is a set of functions for creating containers according to the [OCI container specification v1.0.0](https://github.com/opencontainers/runtime-spec). Beyond that it makes no assumptions about the container runner you choose to use to run the created container.
|
||||
`pkgs.ociTools` is a set of functions for creating containers according to the [OCI container specification v1.0.0](https://github.com/opencontainers/runtime-spec). Beyond that, it makes no assumptions about the container runner you choose to use to run the created container.
|
||||
|
||||
## buildContainer {#ssec-pkgs-ociTools-buildContainer}
|
||||
|
||||
This function creates a simple OCI container that runs a single command inside of it. An OCI container consists of a `config.json` and a rootfs directory.The nix store of the container will contain all referenced dependencies of the given command.
|
||||
This function creates a simple OCI container that runs a single command inside of it. An OCI container consists of a `config.json` and a rootfs directory. The nix store of the container will contain all referenced dependencies of the given command.
|
||||
|
||||
The parameters of `buildContainer` with an example value are described below:
|
||||
|
||||
@ -30,7 +30,7 @@ buildContainer {
|
||||
}
|
||||
```
|
||||
|
||||
- `args` specifies a set of arguments to run inside the container. This is the only required argument for `buildContainer`. All referenced packages inside the derivation will be made available inside the container
|
||||
- `args` specifies a set of arguments to run inside the container. This is the only required argument for `buildContainer`. All referenced packages inside the derivation will be made available inside the container.
|
||||
|
||||
- `mounts` specifies additional mount points chosen by the user. By default only a minimal set of necessary filesystems are mounted into the container (e.g procfs, cgroupfs)
|
||||
|
||||
|
||||
@ -33,7 +33,7 @@ in snapTools.makeSnap {
|
||||
|
||||
## Build a Graphical Snap {#ssec-pkgs-snapTools-build-a-snap-firefox}
|
||||
|
||||
Graphical programs require many more integrations with the host. This example uses Firefox as an example, because it is one of the most complicated programs we could package.
|
||||
Graphical programs require many more integrations with the host. This example uses Firefox as an example because it is one of the most complicated programs we could package.
|
||||
|
||||
``` {#ex-snapTools-buildSnap-firefox .nix}
|
||||
let
|
||||
|
||||
@ -4,13 +4,13 @@ The [Citrix Workspace App](https://www.citrix.com/products/workspace-app/) is a
|
||||
|
||||
## Basic usage {#sec-citrix-base}
|
||||
|
||||
The tarball archive needs to be downloaded manually as the license agreements of the vendor for [Citrix Workspace](https://www.citrix.de/downloads/workspace-app/linux/workspace-app-for-linux-latest.html) needs to be accepted first. Then run `nix-prefetch-url file://$PWD/linuxx64-$version.tar.gz`. With the archive available in the store the package can be built and installed with Nix.
|
||||
The tarball archive needs to be downloaded manually, as the license agreements of the vendor for [Citrix Workspace](https://www.citrix.de/downloads/workspace-app/linux/workspace-app-for-linux-latest.html) needs to be accepted first. Then run `nix-prefetch-url file://$PWD/linuxx64-$version.tar.gz`. With the archive available in the store, the package can be built and installed with Nix.
|
||||
|
||||
## Citrix Selfservice {#sec-citrix-selfservice}
|
||||
## Citrix Self-service {#sec-citrix-selfservice}
|
||||
|
||||
The [selfservice](https://support.citrix.com/article/CTX200337) is an application managing Citrix desktops and applications. Please note that this feature only works with at least citrix_workspace_20_06_0 and later versions.
|
||||
The [self-service](https://support.citrix.com/article/CTX200337) is an application managing Citrix desktops and applications. Please note that this feature only works with at least citrix_workspace_20_06_0 and later versions.
|
||||
|
||||
In order to set this up, you first have to [download the `.cr` file from the Netscaler Gateway](https://its.uiowa.edu/support/article/102186). After that you can configure the `selfservice` like this:
|
||||
In order to set this up, you first have to [download the `.cr` file from the Netscaler Gateway](https://its.uiowa.edu/support/article/102186). After that, you can configure the `selfservice` like this:
|
||||
|
||||
```ShellSession
|
||||
$ storebrowse -C ~/Downloads/receiverconfig.cr
|
||||
@ -19,7 +19,7 @@ $ selfservice
|
||||
|
||||
## Custom certificates {#sec-citrix-custom-certs}
|
||||
|
||||
The `Citrix Workspace App` in `nixpkgs` trusts several certificates [from the Mozilla database](https://curl.haxx.se/docs/caextract.html) by default. However several companies using Citrix might require their own corporate certificate. On distros with imperative packaging these certs can be stored easily in [`$ICAROOT`](https://developer-docs.citrix.com/projects/receiver-for-linux-command-reference/en/13.7/), however this directory is a store path in `nixpkgs`. In order to work around this issue the package provides a simple mechanism to add custom certificates without rebuilding the entire package using `symlinkJoin`:
|
||||
The `Citrix Workspace App` in `nixpkgs` trusts several certificates [from the Mozilla database](https://curl.haxx.se/docs/caextract.html) by default. However, several companies using Citrix might require their own corporate certificate. On distros with imperative packaging, these certs can be stored easily in [`$ICAROOT`](https://developer-docs.citrix.com/projects/receiver-for-linux-command-reference/en/13.7/), however this directory is a store path in `nixpkgs`. In order to work around this issue, the package provides a simple mechanism to add custom certificates without rebuilding the entire package using `symlinkJoin`:
|
||||
|
||||
```nix
|
||||
with import <nixpkgs> { config.allowUnfree = true; };
|
||||
|
||||
@ -8,9 +8,9 @@ Nixpkgs provides a number of packages that will install Eclipse in its various f
|
||||
$ nix-env -f '<nixpkgs>' -qaP -A eclipses --description
|
||||
```
|
||||
|
||||
Once an Eclipse variant is installed it can be run using the `eclipse` command, as expected. From within Eclipse it is then possible to install plugins in the usual manner by either manually specifying an Eclipse update site or by installing the Marketplace Client plugin and using it to discover and install other plugins. This installation method provides an Eclipse installation that closely resemble a manually installed Eclipse.
|
||||
Once an Eclipse variant is installed, it can be run using the `eclipse` command, as expected. From within Eclipse, it is then possible to install plugins in the usual manner by either manually specifying an Eclipse update site or by installing the Marketplace Client plugin and using it to discover and install other plugins. This installation method provides an Eclipse installation that closely resemble a manually installed Eclipse.
|
||||
|
||||
If you prefer to install plugins in a more declarative manner then Nixpkgs also offer a number of Eclipse plugins that can be installed in an _Eclipse environment_. This type of environment is created using the function `eclipseWithPlugins` found inside the `nixpkgs.eclipses` attribute set. This function takes as argument `{ eclipse, plugins ? [], jvmArgs ? [] }` where `eclipse` is a one of the Eclipse packages described above, `plugins` is a list of plugin derivations, and `jvmArgs` is a list of arguments given to the JVM running the Eclipse. For example, say you wish to install the latest Eclipse Platform with the popular Eclipse Color Theme plugin and also allow Eclipse to use more RAM. You could then add
|
||||
If you prefer to install plugins in a more declarative manner, then Nixpkgs also offer a number of Eclipse plugins that can be installed in an _Eclipse environment_. This type of environment is created using the function `eclipseWithPlugins` found inside the `nixpkgs.eclipses` attribute set. This function takes as argument `{ eclipse, plugins ? [], jvmArgs ? [] }` where `eclipse` is a one of the Eclipse packages described above, `plugins` is a list of plugin derivations, and `jvmArgs` is a list of arguments given to the JVM running the Eclipse. For example, say you wish to install the latest Eclipse Platform with the popular Eclipse Color Theme plugin and also allow Eclipse to use more RAM. You could then add:
|
||||
|
||||
```nix
|
||||
packageOverrides = pkgs: {
|
||||
@ -22,15 +22,15 @@ packageOverrides = pkgs: {
|
||||
}
|
||||
```
|
||||
|
||||
to your Nixpkgs configuration (`~/.config/nixpkgs/config.nix`) and install it by running `nix-env -f '<nixpkgs>' -iA myEclipse` and afterward run Eclipse as usual. It is possible to find out which plugins are available for installation using `eclipseWithPlugins` by running
|
||||
to your Nixpkgs configuration (`~/.config/nixpkgs/config.nix`) and install it by running `nix-env -f '<nixpkgs>' -iA myEclipse` and afterward run Eclipse as usual. It is possible to find out which plugins are available for installation using `eclipseWithPlugins` by running:
|
||||
|
||||
```ShellSession
|
||||
$ nix-env -f '<nixpkgs>' -qaP -A eclipses.plugins --description
|
||||
```
|
||||
|
||||
If there is a need to install plugins that are not available in Nixpkgs then it may be possible to define these plugins outside Nixpkgs using the `buildEclipseUpdateSite` and `buildEclipsePlugin` functions found in the `nixpkgs.eclipses.plugins` attribute set. Use the `buildEclipseUpdateSite` function to install a plugin distributed as an Eclipse update site. This function takes `{ name, src }` as argument where `src` indicates the Eclipse update site archive. All Eclipse features and plugins within the downloaded update site will be installed. When an update site archive is not available then the `buildEclipsePlugin` function can be used to install a plugin that consists of a pair of feature and plugin JARs. This function takes an argument `{ name, srcFeature, srcPlugin }` where `srcFeature` and `srcPlugin` are the feature and plugin JARs, respectively.
|
||||
If there is a need to install plugins that are not available in Nixpkgs then it may be possible to define these plugins outside Nixpkgs using the `buildEclipseUpdateSite` and `buildEclipsePlugin` functions found in the `nixpkgs.eclipses.plugins` attribute set. Use the `buildEclipseUpdateSite` function to install a plugin distributed as an Eclipse update site. This function takes `{ name, src }` as argument, where `src` indicates the Eclipse update site archive. All Eclipse features and plugins within the downloaded update site will be installed. When an update site archive is not available, then the `buildEclipsePlugin` function can be used to install a plugin that consists of a pair of feature and plugin JARs. This function takes an argument `{ name, srcFeature, srcPlugin }` where `srcFeature` and `srcPlugin` are the feature and plugin JARs, respectively.
|
||||
|
||||
Expanding the previous example with two plugins using the above functions we have
|
||||
Expanding the previous example with two plugins using the above functions, we have:
|
||||
|
||||
```nix
|
||||
packageOverrides = pkgs: {
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Elm {#sec-elm}
|
||||
|
||||
To start a development environment do
|
||||
To start a development environment, run:
|
||||
|
||||
```ShellSession
|
||||
nix-shell -p elmPackages.elm elmPackages.elm-format
|
||||
|
||||
@ -20,7 +20,7 @@ The Emacs package comes with some extra helpers to make it easier to configure.
|
||||
}
|
||||
```
|
||||
|
||||
You can install it like any other packages via `nix-env -iA myEmacs`. However, this will only install those packages. It will not `configure` them for us. To do this, we need to provide a configuration file. Luckily, it is possible to do this from within Nix! By modifying the above example, we can make Emacs load a custom config file. The key is to create a package that provide a `default.el` file in `/share/emacs/site-start/`. Emacs knows to load this file automatically when it starts.
|
||||
You can install it like any other packages via `nix-env -iA myEmacs`. However, this will only install those packages. It will not `configure` them for us. To do this, we need to provide a configuration file. Luckily, it is possible to do this from within Nix! By modifying the above example, we can make Emacs load a custom config file. The key is to create a package that provides a `default.el` file in `/share/emacs/site-start/`. Emacs knows to load this file automatically when it starts.
|
||||
|
||||
```nix
|
||||
{
|
||||
@ -101,9 +101,9 @@ You can install it like any other packages via `nix-env -iA myEmacs`. However, t
|
||||
}
|
||||
```
|
||||
|
||||
This provides a fairly full Emacs start file. It will load in addition to the user's presonal config. You can always disable it by passing `-q` to the Emacs command.
|
||||
This provides a fairly full Emacs start file. It will load in addition to the user's personal config. You can always disable it by passing `-q` to the Emacs command.
|
||||
|
||||
Sometimes `emacs.pkgs.withPackages` is not enough, as this package set has some priorities imposed on packages (with the lowest priority assigned to Melpa Unstable, and the highest for packages manually defined in `pkgs/top-level/emacs-packages.nix`). But you can't control this priorities when some package is installed as a dependency. You can override it on per-package-basis, providing all the required dependencies manually - but it's tedious and there is always a possibility that an unwanted dependency will sneak in through some other package. To completely override such a package you can use `overrideScope'`.
|
||||
Sometimes `emacs.pkgs.withPackages` is not enough, as this package set has some priorities imposed on packages (with the lowest priority assigned to Melpa Unstable, and the highest for packages manually defined in `pkgs/top-level/emacs-packages.nix`). But you can't control these priorities when some package is installed as a dependency. You can override it on a per-package-basis, providing all the required dependencies manually, but it's tedious and there is always a possibility that an unwanted dependency will sneak in through some other package. To completely override such a package, you can use `overrideScope'`.
|
||||
|
||||
```nix
|
||||
overrides = self: super: rec {
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
# /etc files {#etc}
|
||||
|
||||
Certain calls in glibc require access to runtime files found in /etc such as `/etc/protocols` or `/etc/services` -- [getprotobyname](https://linux.die.net/man/3/getprotobyname) is one such function.
|
||||
Certain calls in glibc require access to runtime files found in `/etc` such as `/etc/protocols` or `/etc/services` -- [getprotobyname](https://linux.die.net/man/3/getprotobyname) is one such function.
|
||||
|
||||
On non-NixOS distributions these files are typically provided by packages (i.e. [netbase](https://packages.debian.org/sid/netbase)) if not already pre-installed in your distribution. This can cause non-reproducibility for code if they rely on these files being present.
|
||||
On non-NixOS distributions these files are typically provided by packages (i.e., [netbase](https://packages.debian.org/sid/netbase)) if not already pre-installed in your distribution. This can cause non-reproducibility for code if they rely on these files being present.
|
||||
|
||||
If [iana-etc](https://hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.iana-etc.x86_64-linux) is part of your _buildInputs_ then it will set the environment varaibles `NIX_ETC_PROTOCOLS` and `NIX_ETC_SERVICES` to the corresponding files in the package through a _setup-hook_.
|
||||
If [iana-etc](https://hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.iana-etc.x86_64-linux) is part of your `buildInputs`, then it will set the environment variables `NIX_ETC_PROTOCOLS` and `NIX_ETC_SERVICES` to the corresponding files in the package through a setup hook.
|
||||
|
||||
|
||||
```bash
|
||||
@ -15,4 +15,4 @@ NIX_ETC_SERVICES=/nix/store/aj866hr8fad8flnggwdhrldm0g799ccz-iana-etc-20210225/e
|
||||
NIX_ETC_PROTOCOLS=/nix/store/aj866hr8fad8flnggwdhrldm0g799ccz-iana-etc-20210225/etc/protocols
|
||||
```
|
||||
|
||||
Nixpkg's version of [glibc](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/glibc/default.nix) has been patched to check for the existence of these environment variables. If the environment variable are *not set*, then it will attempt to find the files at the default location within _/etc_.
|
||||
Nixpkg's version of [glibc](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/glibc/default.nix) has been patched to check for the existence of these environment variables. If the environment variables are *not* set, then it will attempt to find the files at the default location within `/etc`.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
## Build wrapped Firefox with extensions and policies {#build-wrapped-firefox-with-extensions-and-policies}
|
||||
|
||||
The `wrapFirefox` function allows to pass policies, preferences and extension that are available to Firefox. With the help of `fetchFirefoxAddon` this allows build a Firefox version that already comes with addons pre-installed:
|
||||
The `wrapFirefox` function allows to pass policies, preferences and extensions that are available to Firefox. With the help of `fetchFirefoxAddon` this allows to build a Firefox version that already comes with add-ons pre-installed:
|
||||
|
||||
```nix
|
||||
{
|
||||
@ -26,10 +26,14 @@ The `wrapFirefox` function allows to pass policies, preferences and extension th
|
||||
Pocket = false;
|
||||
Snippets = false;
|
||||
};
|
||||
UserMessaging = {
|
||||
ExtensionRecommendations = false;
|
||||
SkipOnboarding = true;
|
||||
};
|
||||
UserMessaging = {
|
||||
ExtensionRecommendations = false;
|
||||
SkipOnboarding = true;
|
||||
};
|
||||
SecurityDevices = {
|
||||
# Use a proxy module rather than `nixpkgs.config.firefox.smartcardSupport = true`
|
||||
"PKCS#11 Proxy Module" = "${pkgs.p11-kit}/lib/p11-kit-proxy.so";
|
||||
};
|
||||
};
|
||||
|
||||
extraPrefs = ''
|
||||
@ -40,13 +44,12 @@ The `wrapFirefox` function allows to pass policies, preferences and extension th
|
||||
}
|
||||
```
|
||||
|
||||
If `nixExtensions != null` then all manually installed addons will be uninstalled from your browser profile.
|
||||
To view available enterprise policies visit [enterprise policies](https://github.com/mozilla/policy-templates#enterprisepoliciesenabled)
|
||||
or type into the Firefox url bar: `about:policies#documentation`.
|
||||
Nix installed addons do not have a valid signature, which is why signature verification is disabled. This does not compromise security because downloaded addons are checksumed and manual addons can't be installed. Also make sure that the `name` field of fetchFirefoxAddon is unique. If you remove an addon from the nixExtensions array, rebuild and start Firefox the removed addon will be completly removed with all of its settings.
|
||||
If `nixExtensions != null`, then all manually installed add-ons will be uninstalled from your browser profile.
|
||||
To view available enterprise policies, visit [enterprise policies](https://github.com/mozilla/policy-templates#enterprisepoliciesenabled)
|
||||
or type into the Firefox URL bar: `about:policies#documentation`.
|
||||
Nix installed add-ons do not have a valid signature, which is why signature verification is disabled. This does not compromise security because downloaded add-ons are checksummed and manual add-ons can't be installed. Also, make sure that the `name` field of `fetchFirefoxAddon` is unique. If you remove an add-on from the `nixExtensions` array, rebuild and start Firefox: the removed add-on will be completely removed with all of its settings.
|
||||
|
||||
## Troubleshooting {#sec-firefox-troubleshooting}
|
||||
If addons are marked as broken or the signature is invalid, make sure you have Firefox ESR installed. Normal Firefox does not provide the ability anymore to disable signature verification for addons thus nix addons get disabled by the normal Firefox binary.
|
||||
|
||||
If addons do not appear installed although they have been defined in your nix configuration file reset the local addon state of your Firefox profile by clicking `help -> restart with addons disabled -> restart -> refresh firefox`. This can happen if you switch from manual addon mode to nix addon mode and then back to manual mode and then again to nix addon mode.
|
||||
If add-ons are marked as broken or the signature is invalid, make sure you have Firefox ESR installed. Normal Firefox does not provide the ability anymore to disable signature verification for add-ons thus nix add-ons get disabled by the normal Firefox binary.
|
||||
|
||||
If add-ons do not appear installed despite being defined in your nix configuration file, reset the local add-on state of your Firefox profile by clicking `Help -> More Troubleshooting Information -> Refresh Firefox`. This can happen if you switch from manual add-on mode to nix add-on mode and then back to manual mode and then again to nix add-on mode.
|
||||
|
||||
@ -36,7 +36,7 @@ using `buildFishPlugin` and running unit tests with the `fishtape` test runner.
|
||||
## Fish wrapper {#sec-fish-wrapper}
|
||||
|
||||
The `wrapFish` package is a wrapper around Fish which can be used to create
|
||||
Fish shells initialised with some plugins as well as completions, configuration
|
||||
Fish shells initialized with some plugins as well as completions, configuration
|
||||
snippets and functions sourced from the given paths. This provides a convenient
|
||||
way to test Fish plugins and scripts without having to alter the environment.
|
||||
|
||||
|
||||
@ -24,10 +24,10 @@ packages on macOS:
|
||||
checking for fuse.h... no
|
||||
configure: error: No fuse.h found.
|
||||
|
||||
This happens on autoconf based projects that uses `AC_CHECK_HEADERS` or
|
||||
This happens on autoconf based projects that use `AC_CHECK_HEADERS` or
|
||||
`AC_CHECK_LIBS` to detect libfuse, and will occur even when the `fuse` package
|
||||
is included in `buildInputs`. It happens because libfuse headers throw an error
|
||||
on macOS if the `FUSE_USE_VERSION` macro is undefined. Many proejcts do define
|
||||
on macOS if the `FUSE_USE_VERSION` macro is undefined. Many projects do define
|
||||
`FUSE_USE_VERSION`, but only inside C source files. This results in the above
|
||||
error at configure time because the configure script would attempt to compile
|
||||
sample FUSE programs without defining `FUSE_USE_VERSION`.
|
||||
|
||||
@ -6,7 +6,7 @@ This package is an ibus-based completion method to speed up typing.
|
||||
|
||||
IBus needs to be configured accordingly to activate `typing-booster`. The configuration depends on the desktop manager in use. For detailed instructions, please refer to the [upstream docs](https://mike-fabian.github.io/ibus-typing-booster/documentation.html).
|
||||
|
||||
On NixOS you need to explicitly enable `ibus` with given engines before customizing your desktop to use `typing-booster`. This can be achieved using the `ibus` module:
|
||||
On NixOS, you need to explicitly enable `ibus` with given engines before customizing your desktop to use `typing-booster`. This can be achieved using the `ibus` module:
|
||||
|
||||
```nix
|
||||
{ pkgs, ... }: {
|
||||
@ -19,7 +19,7 @@ On NixOS you need to explicitly enable `ibus` with given engines before customiz
|
||||
|
||||
## Using custom hunspell dictionaries {#sec-ibus-typing-booster-customize-hunspell}
|
||||
|
||||
The IBus engine is based on `hunspell` to support completion in many languages. By default the dictionaries `de-de`, `en-us`, `fr-moderne` `es-es`, `it-it`, `sv-se` and `sv-fi` are in use. To add another dictionary, the package can be overridden like this:
|
||||
The IBus engine is based on `hunspell` to support completion in many languages. By default, the dictionaries `de-de`, `en-us`, `fr-moderne` `es-es`, `it-it`, `sv-se` and `sv-fi` are in use. To add another dictionary, the package can be overridden like this:
|
||||
|
||||
```nix
|
||||
ibus-engines.typing-booster.override { langs = [ "de-at" "en-gb" ]; }
|
||||
@ -31,7 +31,7 @@ _Note: each language passed to `langs` must be an attribute name in `pkgs.hunspe
|
||||
|
||||
The `ibus-engines.typing-booster` package contains a program named `emoji-picker`. To display all emojis correctly, a special font such as `noto-fonts-emoji` is needed:
|
||||
|
||||
On NixOS it can be installed using the following expression:
|
||||
On NixOS, it can be installed using the following expression:
|
||||
|
||||
```nix
|
||||
{ pkgs, ... }: { fonts.fonts = with pkgs; [ noto-fonts-emoji ]; }
|
||||
|
||||
@ -4,7 +4,7 @@ The Nix expressions to build the Linux kernel are in [`pkgs/os-specific/linux/ke
|
||||
|
||||
The function that builds the kernel has an argument `kernelPatches` which should be a list of `{name, patch, extraConfig}` attribute sets, where `name` is the name of the patch (which is included in the kernel’s `meta.description` attribute), `patch` is the patch itself (possibly compressed), and `extraConfig` (optional) is a string specifying extra options to be concatenated to the kernel configuration file (`.config`).
|
||||
|
||||
The kernel derivation exports an attribute `features` specifying whether optional functionality is or isn’t enabled. This is used in NixOS to implement kernel-specific behaviour. For instance, if the kernel has the `iwlwifi` feature (i.e. has built-in support for Intel wireless chipsets), then NixOS doesn’t have to build the external `iwlwifi` package:
|
||||
The kernel derivation exports an attribute `features` specifying whether optional functionality is or isn’t enabled. This is used in NixOS to implement kernel-specific behaviour. For instance, if the kernel has the `iwlwifi` feature (i.e., has built-in support for Intel wireless chipsets), then NixOS doesn’t have to build the external `iwlwifi` package:
|
||||
|
||||
```nix
|
||||
modulesTree = [kernel]
|
||||
@ -14,19 +14,19 @@ modulesTree = [kernel]
|
||||
|
||||
How to add a new (major) version of the Linux kernel to Nixpkgs:
|
||||
|
||||
1. Copy the old Nix expression (e.g. `linux-2.6.21.nix`) to the new one (e.g. `linux-2.6.22.nix`) and update it.
|
||||
1. Copy the old Nix expression (e.g., `linux-2.6.21.nix`) to the new one (e.g., `linux-2.6.22.nix`) and update it.
|
||||
|
||||
2. Add the new kernel to the `kernels` attribute set in `linux-kernels.nix` (e.g., create an attribute `kernel_2_6_22`).
|
||||
|
||||
3. Now we’re going to update the kernel configuration. First unpack the kernel. Then for each supported platform (`i686`, `x86_64`, `uml`) do the following:
|
||||
|
||||
1. Make an copy from the old config (e.g. `config-2.6.21-i686-smp`) to the new one (e.g. `config-2.6.22-i686-smp`).
|
||||
1. Make a copy from the old config (e.g., `config-2.6.21-i686-smp`) to the new one (e.g., `config-2.6.22-i686-smp`).
|
||||
|
||||
2. Copy the config file for this platform (e.g. `config-2.6.22-i686-smp`) to `.config` in the kernel source tree.
|
||||
2. Copy the config file for this platform (e.g., `config-2.6.22-i686-smp`) to `.config` in the kernel source tree.
|
||||
|
||||
3. Run `make oldconfig ARCH={i386,x86_64,um}` and answer all questions. (For the uml configuration, also add `SHELL=bash`.) Make sure to keep the configuration consistent between platforms (i.e. don’t enable some feature on `i686` and disable it on `x86_64`).
|
||||
3. Run `make oldconfig ARCH={i386,x86_64,um}` and answer all questions. (For the uml configuration, also add `SHELL=bash`.) Make sure to keep the configuration consistent between platforms (i.e., don’t enable some feature on `i686` and disable it on `x86_64`).
|
||||
|
||||
4. If needed you can also run `make menuconfig`:
|
||||
4. If needed, you can also run `make menuconfig`:
|
||||
|
||||
```ShellSession
|
||||
$ nix-env -f "<nixpkgs>" -iA ncurses
|
||||
@ -34,7 +34,7 @@ How to add a new (major) version of the Linux kernel to Nixpkgs:
|
||||
$ make menuconfig ARCH=arch
|
||||
```
|
||||
|
||||
5. Copy `.config` over the new config file (e.g. `config-2.6.22-i686-smp`).
|
||||
5. Copy `.config` over the new config file (e.g., `config-2.6.22-i686-smp`).
|
||||
|
||||
4. Test building the kernel: `nix-build -A linuxKernel.kernels.kernel_2_6_22`. If it compiles, ship it! For extra credit, try booting NixOS with it.
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
# Locales {#locales}
|
||||
|
||||
To allow simultaneous use of packages linked against different versions of `glibc` with different locale archive formats Nixpkgs patches `glibc` to rely on `LOCALE_ARCHIVE` environment variable.
|
||||
To allow simultaneous use of packages linked against different versions of `glibc` with different locale archive formats, Nixpkgs patches `glibc` to rely on `LOCALE_ARCHIVE` environment variable.
|
||||
|
||||
On non-NixOS distributions this variable is obviously not set. This can cause regressions in language support or even crashes in some Nixpkgs-provided programs. The simplest way to mitigate this problem is exporting the `LOCALE_ARCHIVE` variable pointing to `${glibcLocales}/lib/locale/locale-archive`. The drawback (and the reason this is not the default) is the relatively large (a hundred MiB) size of the full set of locales. It is possible to build a custom set of locales by overriding parameters `allLocales` and `locales` of the package.
|
||||
On non-NixOS distributions, this variable is obviously not set. This can cause regressions in language support or even crashes in some Nixpkgs-provided programs. The simplest way to mitigate this problem is exporting the `LOCALE_ARCHIVE` variable pointing to `${glibcLocales}/lib/locale/locale-archive`. The drawback (and the reason this is not the default) is the relatively large (a hundred MiB) size of the full set of locales. It is possible to build a custom set of locales by overriding parameters `allLocales` and `locales` of the package.
|
||||
|
||||
@ -4,8 +4,8 @@
|
||||
|
||||
## ETags on static files served from the Nix store {#sec-nginx-etag}
|
||||
|
||||
HTTP has a couple different mechanisms for caching to prevent clients from having to download the same content repeatedly if a resource has not changed since the last time it was requested. When nginx is used as a server for static files, it implements the caching mechanism based on the [`Last-Modified`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified) response header automatically; unfortunately, it works by using filesystem timestamps to determine the value of the `Last-Modified` header. This doesn't give the desired behavior when the file is in the Nix store, because all file timestamps are set to 0 (for reasons related to build reproducibility).
|
||||
HTTP has a couple of different mechanisms for caching to prevent clients from having to download the same content repeatedly if a resource has not changed since the last time it was requested. When nginx is used as a server for static files, it implements the caching mechanism based on the [`Last-Modified`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified) response header automatically; unfortunately, it works by using filesystem timestamps to determine the value of the `Last-Modified` header. This doesn't give the desired behavior when the file is in the Nix store because all file timestamps are set to 0 (for reasons related to build reproducibility).
|
||||
|
||||
Fortunately, HTTP supports an alternative (and more effective) caching mechanism: the [`ETag`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) response header. The value of the `ETag` header specifies some identifier for the particular content that the server is sending (e.g. a hash). When a client makes a second request for the same resource, it sends that value back in an `If-None-Match` header. If the ETag value is unchanged, then the server does not need to resend the content.
|
||||
Fortunately, HTTP supports an alternative (and more effective) caching mechanism: the [`ETag`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) response header. The value of the `ETag` header specifies some identifier for the particular content that the server is sending (e.g., a hash). When a client makes a second request for the same resource, it sends that value back in an `If-None-Match` header. If the ETag value is unchanged, then the server does not need to resend the content.
|
||||
|
||||
As of NixOS 19.09, the nginx package in Nixpkgs is patched such that when nginx serves a file out of `/nix/store`, the hash in the store path is used as the `ETag` header in the HTTP response, thus providing proper caching functionality. This happens automatically; you do not need to do modify any configuration to get this behavior.
|
||||
|
||||
@ -12,4 +12,4 @@ The NixOS desktop or other non-headless configurations are the primary target fo
|
||||
|
||||
If you are using a non-NixOS GNU/Linux/X11 desktop with free software video drivers, consider launching OpenGL-dependent programs from Nixpkgs with Nixpkgs versions of `libglvnd` and `mesa.drivers` in `LD_LIBRARY_PATH`. For Mesa drivers, the Linux kernel version doesn't have to match nixpkgs.
|
||||
|
||||
For proprietary video drivers you might have luck with also adding the corresponding video driver package.
|
||||
For proprietary video drivers, you might have luck with also adding the corresponding video driver package.
|
||||
|
||||
@ -4,7 +4,7 @@ Some packages provide the shell integration to be more useful. But unlike other
|
||||
|
||||
- `fzf` : `fzf-share`
|
||||
|
||||
E.g. `fzf` can then used in the `.bashrc` like this:
|
||||
E.g. `fzf` can then be used in the `.bashrc` like this:
|
||||
|
||||
```bash
|
||||
source "$(fzf-share)/completion.bash"
|
||||
|
||||
@ -2,20 +2,20 @@
|
||||
|
||||
## Steam in Nix {#sec-steam-nix}
|
||||
|
||||
Steam is distributed as a `.deb` file, for now only as an i686 package (the amd64 package only has documentation). When unpacked, it has a script called `steam` that in Ubuntu (their target distro) would go to `/usr/bin`. When run for the first time, this script copies some files to the user's home, which include another script that is the ultimate responsible for launching the steam binary, which is also in \$HOME.
|
||||
Steam is distributed as a `.deb` file, for now only as an i686 package (the amd64 package only has documentation). When unpacked, it has a script called `steam` that in Ubuntu (their target distro) would go to `/usr/bin`. When run for the first time, this script copies some files to the user's home, which include another script that is the ultimate responsible for launching the steam binary, which is also in `$HOME`.
|
||||
|
||||
Nix problems and constraints:
|
||||
|
||||
- We don't have `/bin/bash` and many scripts point there. Similarly for `/usr/bin/python`.
|
||||
- We don't have `/bin/bash` and many scripts point there. Same thing for `/usr/bin/python`.
|
||||
- We don't have the dynamic loader in `/lib`.
|
||||
- The `steam.sh` script in \$HOME can not be patched, as it is checked and rewritten by steam.
|
||||
- The `steam.sh` script in `$HOME` cannot be patched, as it is checked and rewritten by steam.
|
||||
- The steam binary cannot be patched, it's also checked.
|
||||
|
||||
The current approach to deploy Steam in NixOS is composing a FHS-compatible chroot environment, as documented [here](http://sandervanderburg.blogspot.nl/2013/09/composing-fhs-compatible-chroot.html). This allows us to have binaries in the expected paths without disrupting the system, and to avoid patching them to work in a non FHS environment.
|
||||
|
||||
## How to play {#sec-steam-play}
|
||||
|
||||
Use `programs.steam.enable = true;` if you want to add steam to systemPackages and also enable a few workarrounds aswell as Steam controller support or other Steam supported controllers such as the DualShock 4 or Nintendo Switch Pr.
|
||||
Use `programs.steam.enable = true;` if you want to add steam to `systemPackages` and also enable a few workarounds as well as Steam controller support or other Steam supported controllers such as the DualShock 4 or Nintendo Switch Pro Controller.
|
||||
|
||||
## Troubleshooting {#sec-steam-troub}
|
||||
|
||||
@ -32,7 +32,7 @@ Use `programs.steam.enable = true;` if you want to add steam to systemPackages a
|
||||
- **Using the FOSS Radeon or nouveau (nvidia) drivers**
|
||||
|
||||
- The `newStdcpp` parameter was removed since NixOS 17.09 and should not be needed anymore.
|
||||
- Steam ships statically linked with a version of libcrypto that conflics with the one dynamically loaded by radeonsi_dri.so. If you get the error
|
||||
- Steam ships statically linked with a version of `libcrypto` that conflicts with the one dynamically loaded by radeonsi_dri.so. If you get the error:
|
||||
|
||||
```
|
||||
steam.sh: line 713: 7842 Segmentation fault (core dumped)
|
||||
@ -42,13 +42,13 @@ Use `programs.steam.enable = true;` if you want to add steam to systemPackages a
|
||||
|
||||
- **Java**
|
||||
|
||||
1. There is no java in steam chrootenv by default. If you get a message like
|
||||
1. There is no java in steam chrootenv by default. If you get a message like:
|
||||
|
||||
```
|
||||
/home/foo/.local/share/Steam/SteamApps/common/towns/towns.sh: line 1: java: command not found
|
||||
```
|
||||
|
||||
you need to add
|
||||
you need to add:
|
||||
|
||||
```nix
|
||||
steam.override { withJava = true; };
|
||||
@ -56,7 +56,7 @@ Use `programs.steam.enable = true;` if you want to add steam to systemPackages a
|
||||
|
||||
## steam-run {#sec-steam-run}
|
||||
|
||||
The FHS-compatible chroot used for Steam can also be used to run other Linux games that expect a FHS environment. To use it, install the `steam-run` package and run the game with
|
||||
The FHS-compatible chroot used for Steam can also be used to run other Linux games that expect a FHS environment. To use it, install the `steam-run` package and run the game with:
|
||||
|
||||
```
|
||||
steam-run ./foo
|
||||
|
||||
@ -4,7 +4,7 @@ Urxvt, also known as rxvt-unicode, is a highly customizable terminal emulator.
|
||||
|
||||
## Configuring urxvt {#sec-urxvt-conf}
|
||||
|
||||
In `nixpkgs`, urxvt is provided by the package `rxvt-unicode`. It can be configured to include your choice of plugins, reducing its closure size from the default configuration which includes all available plugins. To make use of this functionality, use an overlay or directly install an expression that overrides its configuration, such as
|
||||
In `nixpkgs`, urxvt is provided by the package `rxvt-unicode`. It can be configured to include your choice of plugins, reducing its closure size from the default configuration which includes all available plugins. To make use of this functionality, use an overlay or directly install an expression that overrides its configuration, such as:
|
||||
|
||||
```nix
|
||||
rxvt-unicode.override {
|
||||
@ -58,14 +58,14 @@ rxvt-unicode.override {
|
||||
|
||||
## Packaging urxvt plugins {#sec-urxvt-pkg}
|
||||
|
||||
Urxvt plugins resides in `pkgs/applications/misc/rxvt-unicode-plugins`. To add a new plugin create an expression in a subdirectory and add the package to the set in `pkgs/applications/misc/rxvt-unicode-plugins/default.nix`.
|
||||
Urxvt plugins resides in `pkgs/applications/misc/rxvt-unicode-plugins`. To add a new plugin, create an expression in a subdirectory and add the package to the set in `pkgs/applications/misc/rxvt-unicode-plugins/default.nix`.
|
||||
|
||||
A plugin can be any kind of derivation, the only requirement is that it should always install perl scripts in `$out/lib/urxvt/perl`. Look for existing plugins for examples.
|
||||
|
||||
If the plugin is itself a perl package that needs to be imported from other plugins or scripts, add the following passthrough:
|
||||
If the plugin is itself a Perl package that needs to be imported from other plugins or scripts, add the following passthrough:
|
||||
|
||||
```nix
|
||||
passthru.perlPackages = [ "self" ];
|
||||
```
|
||||
|
||||
This will make the urxvt wrapper pick up the dependency and set up the perl path accordingly.
|
||||
This will make the urxvt wrapper pick up the dependency and set up the Perl path accordingly.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Weechat {#sec-weechat}
|
||||
# WeeChat {#sec-weechat}
|
||||
|
||||
Weechat can be configured to include your choice of plugins, reducing its closure size from the default configuration which includes all available plugins. To make use of this functionality, install an expression that overrides its configuration such as
|
||||
WeeChat can be configured to include your choice of plugins, reducing its closure size from the default configuration which includes all available plugins. To make use of this functionality, install an expression that overrides its configuration, such as:
|
||||
|
||||
```nix
|
||||
weechat.override {configure = {availablePlugins, ...}: {
|
||||
@ -13,7 +13,7 @@ If the `configure` function returns an attrset without the `plugins` attribute,
|
||||
|
||||
The plugins currently available are `python`, `perl`, `ruby`, `guile`, `tcl` and `lua`.
|
||||
|
||||
The python and perl plugins allows the addition of extra libraries. For instance, the `inotify.py` script in `weechat-scripts` requires D-Bus or libnotify, and the `fish.py` script requires `pycrypto`. To use these scripts, use the plugin's `withPackages` attribute:
|
||||
The Python and Perl plugins allows the addition of extra libraries. For instance, the `inotify.py` script in `weechat-scripts` requires D-Bus or libnotify, and the `fish.py` script requires `pycrypto`. To use these scripts, use the plugin's `withPackages` attribute:
|
||||
|
||||
```nix
|
||||
weechat.override { configure = {availablePlugins, ...}: {
|
||||
@ -49,7 +49,7 @@ weechat.override {
|
||||
|
||||
Further values can be added to the list of commands when running `weechat --run-command "your-commands"`.
|
||||
|
||||
Additionally it's possible to specify scripts to be loaded when starting `weechat`. These will be loaded before the commands from `init`:
|
||||
Additionally, it's possible to specify scripts to be loaded when starting `weechat`. These will be loaded before the commands from `init`:
|
||||
|
||||
```nix
|
||||
weechat.override {
|
||||
@ -64,7 +64,7 @@ weechat.override {
|
||||
}
|
||||
```
|
||||
|
||||
In `nixpkgs` there's a subpackage which contains derivations for WeeChat scripts. Such derivations expect a `passthru.scripts` attribute which contains a list of all scripts inside the store path. Furthermore all scripts have to live in `$out/share`. An exemplary derivation looks like this:
|
||||
In `nixpkgs` there's a subpackage which contains derivations for WeeChat scripts. Such derivations expect a `passthru.scripts` attribute, which contains a list of all scripts inside the store path. Furthermore, all scripts have to live in `$out/share`. An exemplary derivation looks like this:
|
||||
|
||||
```nix
|
||||
{ stdenv, fetchurl }:
|
||||
|
||||
@ -80,3 +80,49 @@ tests.fetchgit = invalidateFetcherByDrvHash fetchgit {
|
||||
sha256 = "sha256-7DszvbCNTjpzGRmpIVAWXk20P0/XTrWZ79KSOGLrUWY=";
|
||||
};
|
||||
```
|
||||
|
||||
## `nixosTest` {#tester-nixosTest}
|
||||
|
||||
Run a NixOS VM network test using this evaluation of Nixpkgs.
|
||||
|
||||
NOTE: This function is primarily for external use. NixOS itself uses `make-test-python.nix` directly. Packages defined in Nixpkgs [reuse NixOS tests via `nixosTests`, plural](#ssec-nixos-tests-linking).
|
||||
|
||||
It is mostly equivalent to the function `import ./make-test-python.nix` from the
|
||||
[NixOS manual](https://nixos.org/nixos/manual/index.html#sec-nixos-tests),
|
||||
except that the current application of Nixpkgs (`pkgs`) will be used, instead of
|
||||
letting NixOS invoke Nixpkgs anew.
|
||||
|
||||
If a test machine needs to set NixOS options under `nixpkgs`, it must set only the
|
||||
`nixpkgs.pkgs` option.
|
||||
|
||||
### Parameter
|
||||
|
||||
A [NixOS VM test network](https://nixos.org/nixos/manual/index.html#sec-nixos-tests), or path to it. Example:
|
||||
|
||||
```nix
|
||||
{
|
||||
name = "my-test";
|
||||
nodes = {
|
||||
machine1 = { lib, pkgs, nodes, ... }: {
|
||||
environment.systemPackages = [ pkgs.hello ];
|
||||
services.foo.enable = true;
|
||||
};
|
||||
# machine2 = ...;
|
||||
};
|
||||
testScript = ''
|
||||
start_all()
|
||||
machine1.wait_for_unit("foo.service")
|
||||
machine1.succeed("hello | foo-send")
|
||||
'';
|
||||
}
|
||||
```
|
||||
|
||||
### Result
|
||||
|
||||
A derivation that runs the VM test.
|
||||
|
||||
Notable attributes:
|
||||
|
||||
* `nodes`: the evaluated NixOS configurations. Useful for debugging and exploring the configuration.
|
||||
|
||||
* `driverInteractive`: a script that launches an interactive Python session in the context of the `testScript`.
|
||||
|
||||
@ -35,10 +35,10 @@ This works just like `runCommand`. The only difference is that it also provides
|
||||
|
||||
## `runCommandLocal` {#trivial-builder-runCommandLocal}
|
||||
|
||||
Variant of `runCommand` that forces the derivation to be built locally, it is not substituted. This is intended for very cheap commands (<1s execution time). It saves on the network roundrip and can speed up a build.
|
||||
Variant of `runCommand` that forces the derivation to be built locally, it is not substituted. This is intended for very cheap commands (<1s execution time). It saves on the network round-trip and can speed up a build.
|
||||
|
||||
::: {.note}
|
||||
This sets [`allowSubstitutes` to `false`](https://nixos.org/nix/manual/#adv-attr-allowSubstitutes), so only use `runCommandLocal` if you are certain the user will always have a builder for the `system` of the derivation. This should be true for most trivial use cases (e.g. just copying some files to a different location or adding symlinks), because there the `system` is usually the same as `builtins.currentSystem`.
|
||||
This sets [`allowSubstitutes` to `false`](https://nixos.org/nix/manual/#adv-attr-allowSubstitutes), so only use `runCommandLocal` if you are certain the user will always have a builder for the `system` of the derivation. This should be true for most trivial use cases (e.g., just copying some files to a different location or adding symlinks) because there the `system` is usually the same as `builtins.currentSystem`.
|
||||
:::
|
||||
|
||||
## `writeTextFile`, `writeText`, `writeTextDir`, `writeScript`, `writeScriptBin` {#trivial-builder-writeText}
|
||||
@ -219,5 +219,5 @@ produces an output path `/nix/store/<hash>-runtime-references` containing
|
||||
/nix/store/<hash>-hello-2.10
|
||||
```
|
||||
|
||||
but none of `hello`'s dependencies, because those are not referenced directly
|
||||
but none of `hello`'s dependencies because those are not referenced directly
|
||||
by `hi`'s output.
|
||||
|
||||
@ -338,6 +338,10 @@ A (typically large) program with a distinct user interface, primarily used inter
|
||||
|
||||
- `applications/terminal-emulators` (e.g. `alacritty` or `rxvt` or `termite`)
|
||||
|
||||
- **If it’s a _file manager_:**
|
||||
|
||||
- `applications/file-managers` (e.g. `mc` or `ranger` or `pcmanfm`)
|
||||
|
||||
- **If it’s for _video playback / editing_:**
|
||||
|
||||
- `applications/video` (e.g. `vlc`)
|
||||
@ -511,6 +515,8 @@ patches = [
|
||||
|
||||
Otherwise, you can add a `.patch` file to the `nixpkgs` repository. In the interest of keeping our maintenance burden to a minimum, only patches that are unique to `nixpkgs` should be added in this way.
|
||||
|
||||
If a patch is available online but does not cleanly apply, it can be modified in some fixed ways by using additional optional arguments for `fetchpatch`. Check [](#fetchpatch) for details.
|
||||
|
||||
```nix
|
||||
patches = [ ./0001-changes.patch ];
|
||||
```
|
||||
@ -538,17 +544,6 @@ If you do need to do create this sort of patch file, one way to do so is with gi
|
||||
$ git diff -a > nixpkgs/pkgs/the/package/0001-changes.patch
|
||||
```
|
||||
|
||||
If a patch is available online but does not cleanly apply, it can be modified in some fixed ways by using additional optional arguments for `fetchpatch`:
|
||||
|
||||
- `relative`: Similar to using `git-diff`'s `--relative` flag, only keep changes inside the specified directory, making paths relative to it.
|
||||
- `stripLen`: Remove the first `stripLen` components of pathnames in the patch.
|
||||
- `extraPrefix`: Prefix pathnames by this string.
|
||||
- `excludes`: Exclude files matching these patterns (applies after the above arguments).
|
||||
- `includes`: Include only files matching these patterns (applies after the above arguments).
|
||||
- `revert`: Revert the patch.
|
||||
|
||||
Note that because the checksum is computed after applying these effects, using or modifying these arguments will have no effect unless the `sha256` argument is changed as well.
|
||||
|
||||
## Package tests {#sec-package-tests}
|
||||
|
||||
Tests are important to ensure quality and make reviews and automatic updates easy.
|
||||
|
||||
@ -27,7 +27,7 @@ If the build succeeds, the manual will be in `./result/share/doc/nixpkgs/manual.
|
||||
|
||||
As per [RFC 0072](https://github.com/NixOS/rfcs/pull/72), all new documentation content should be written in [CommonMark](https://commonmark.org/) Markdown dialect.
|
||||
|
||||
Additionally, the following syntax extensions are currently used:
|
||||
Additional syntax extensions are available, though not all extensions can be used in NixOS option documentation. The following extensions are currently used:
|
||||
|
||||
- []{#ssec-contributing-markup-anchors}
|
||||
Explicitly defined **anchors** on headings, to allow linking to sections. These should be always used, to ensure the anchors can be linked even when the heading text changes, and to prevent conflicts between [automatically assigned identifiers](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/auto_identifiers.md).
|
||||
@ -53,12 +53,22 @@ Additionally, the following syntax extensions are currently used:
|
||||
This syntax is taken from [MyST](https://myst-parser.readthedocs.io/en/latest/using/syntax.html#targets-and-cross-referencing).
|
||||
|
||||
- []{#ssec-contributing-markup-inline-roles}
|
||||
If you want to link to a man page, you can use `` {manpage}`nix.conf(5)` ``, which will turn into {manpage}`nix.conf(5)`.
|
||||
If you want to link to a man page, you can use `` {manpage}`nix.conf(5)` ``, which will turn into {manpage}`nix.conf(5)`. The references will turn into links when a mapping exists in {file}`doc/build-aux/pandoc-filters/link-unix-man-references.lua`.
|
||||
|
||||
The references will turn into links when a mapping exists in {file}`doc/build-aux/pandoc-filters/link-unix-man-references.lua`.
|
||||
A few markups for other kinds of literals are also available:
|
||||
|
||||
- `` {command}`rm -rfi` `` turns into {command}`rm -rfi`
|
||||
- `` {option}`networking.useDHCP` `` turns into {option}`networking.useDHCP`
|
||||
- `` {file}`/etc/passwd` `` turns into {file}`/etc/passwd`
|
||||
|
||||
These literal kinds are used mostly in NixOS option documentation.
|
||||
|
||||
This syntax is taken from [MyST](https://myst-parser.readthedocs.io/en/latest/syntax/syntax.html#roles-an-in-line-extension-point). Though, the feature originates from [reStructuredText](https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-manpage) with slightly different syntax.
|
||||
|
||||
::: {.note}
|
||||
Inline roles are available for option documentation.
|
||||
:::
|
||||
|
||||
- []{#ssec-contributing-markup-admonitions}
|
||||
**Admonitions**, set off from the text to bring attention to something.
|
||||
|
||||
@ -84,6 +94,10 @@ Additionally, the following syntax extensions are currently used:
|
||||
- [`tip`](https://tdg.docbook.org/tdg/5.0/tip.html)
|
||||
- [`warning`](https://tdg.docbook.org/tdg/5.0/warning.html)
|
||||
|
||||
::: {.note}
|
||||
Admonitions are available for option documentation.
|
||||
:::
|
||||
|
||||
- []{#ssec-contributing-markup-definition-lists}
|
||||
[**Definition lists**](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/definition_lists.md), for defining a group of terms:
|
||||
|
||||
|
||||
@ -185,6 +185,111 @@ Sample template for a new module review is provided below.
|
||||
##### Comments
|
||||
```
|
||||
|
||||
## Individual maintainer list {#reviewing-contributions-indvidual-maintainer-list}
|
||||
|
||||
When adding users to `maintainers/maintainer-list.nix`, the following
|
||||
checks should be performed:
|
||||
|
||||
- If the user has specified a GPG key, verify that the commit is
|
||||
signed by their key.
|
||||
|
||||
First, validate that the commit adding the maintainer is signed by
|
||||
the key the maintainer listed. Check out the pull request and
|
||||
compare its signing key with the listed key in the commit.
|
||||
|
||||
If the commit is not signed or it is signed by a different user, ask
|
||||
them to either recommit using that key or to remove their key
|
||||
information.
|
||||
|
||||
Given a maintainter entry like this:
|
||||
|
||||
``` nix
|
||||
{
|
||||
example = {
|
||||
email = "user@example.com";
|
||||
name = "Example User";
|
||||
keys = [{
|
||||
fingerprint = "0000 0000 2A70 6423 0AED 3C11 F04F 7A19 AAA6 3AFE";
|
||||
}];
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
First receive their key from a keyserver:
|
||||
|
||||
$ gpg --recv-keys 0xF04F7A19AAA63AFE
|
||||
gpg: key 0xF04F7A19AAA63AFE: public key "Example <user@example.com>" imported
|
||||
gpg: Total number processed: 1
|
||||
gpg: imported: 1
|
||||
|
||||
Then check the commit is signed by that key:
|
||||
|
||||
$ git log --show-signature
|
||||
commit b87862a4f7d32319b1de428adb6cdbdd3a960153
|
||||
gpg: Signature made Wed Mar 12 13:32:24 2003 +0000
|
||||
gpg: using RSA key 000000002A7064230AED3C11F04F7A19AAA63AFE
|
||||
gpg: Good signature from "Example User <user@example.com>
|
||||
Author: Example User <user@example.com>
|
||||
Date: Wed Mar 12 13:32:24 2003 +0000
|
||||
|
||||
maintainers: adding example
|
||||
|
||||
and validate that there is a `Good signature` and the printed key
|
||||
matches the user's submitted key.
|
||||
|
||||
Note: GitHub's "Verified" label does not display the user's full key
|
||||
fingerprint, and should not be used for validating the key matches.
|
||||
|
||||
- If the user has specified a `github` account name, ensure they have
|
||||
also specified a `githubId` and verify the two match.
|
||||
|
||||
Maintainer entries that include a `github` field must also include
|
||||
their `githubId`. People can and do change their GitHub name
|
||||
frequently, and the ID is used as the official and stable identity
|
||||
of the maintainer.
|
||||
|
||||
Given a maintainer entry like this:
|
||||
|
||||
``` nix
|
||||
{
|
||||
example = {
|
||||
email = "user@example.com";
|
||||
name = "Example User";
|
||||
github = "ghost";
|
||||
githubId = 10137;
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
First, make sure that the listed GitHub handle matches the author of
|
||||
the commit.
|
||||
|
||||
Then, visit the URL `https://api.github.com/users/ghost` and
|
||||
validate that the `id` field matches the provided `githubId`.
|
||||
|
||||
## Maintainer teams {#reviewing-contributions-maintainer-teams}
|
||||
|
||||
Feel free to create a new maintainer team in `maintainers/team-list.nix`
|
||||
when a group is collectively responsible for a collection of packages.
|
||||
Use taste and personal judgement when deciding if a team is warranted.
|
||||
|
||||
Teams are allowed to define their own rules about membership.
|
||||
|
||||
For example, some teams will represent a business or other group which
|
||||
wants to carefully track its members. Other teams may be very open about
|
||||
who can join, and allow anybody to participate.
|
||||
|
||||
When reviewing changes to a team, read the team's scope and the context
|
||||
around the member list for indications about the team's membership
|
||||
policy.
|
||||
|
||||
In any case, request reviews from the existing team members. If the team
|
||||
lists no specific membership policy, feel free to merge changes to the
|
||||
team after giving the existing members a few days to respond.
|
||||
|
||||
*Important:* If a team says it is a closed group, do not merge additions
|
||||
to the team without an approval by at least one existing member.
|
||||
|
||||
## Other submissions {#reviewing-contributions-other-submissions}
|
||||
|
||||
Other type of submissions requires different reviewing steps.
|
||||
|
||||
@ -96,7 +96,7 @@ We use jbidwatcher as an example for a discontinued project here.
|
||||
|
||||
1. Have Nixpkgs checked out locally and up to date.
|
||||
1. Create a new branch for your change, e.g. `git checkout -b jbidwatcher`
|
||||
1. Remove the actual package including its directory, e.g. `rm -rf pkgs/applications/misc/jbidwatcher`
|
||||
1. Remove the actual package including its directory, e.g. `git rm -rf pkgs/applications/misc/jbidwatcher`
|
||||
1. Remove the package from the list of all packages (`pkgs/top-level/all-packages.nix`).
|
||||
1. Add an alias for the package name in `pkgs/top-level/aliases.nix` (There is also `pkgs/applications/editors/vim/plugins/aliases.nix`. Package sets typically do not have aliases, so we can't add them there.)
|
||||
|
||||
@ -227,7 +227,7 @@ digraph {
|
||||
}
|
||||
```
|
||||
|
||||
[This GitHub Action](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/periodic-merge-6h.yml) brings changes from `master` to `staging-next` and from `staging-next` to `staging` every 6 hours.
|
||||
[This GitHub Action](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/periodic-merge-6h.yml) brings changes from `master` to `staging-next` and from `staging-next` to `staging` every 6 hours; these are the blue arrows in the diagram above. The purple arrows in the diagram above are done manually and much less frequently. You can get an idea of how often these merges occur by looking at the git history.
|
||||
|
||||
|
||||
### Master branch {#submitting-changes-master-branch}
|
||||
@ -236,7 +236,7 @@ The `master` branch is the main development branch. It should only see non-break
|
||||
|
||||
### Staging branch {#submitting-changes-staging-branch}
|
||||
|
||||
The `staging` branch is a development branch where mass-rebuilds go. It should only see non-breaking mass-rebuild commits. That means it is not to be used for testing, and changes must have been well tested already. If the branch is already in a broken state, please refrain from adding extra new breakages.
|
||||
The `staging` branch is a development branch where mass-rebuilds go. Mass rebuilds are commits that cause rebuilds for many packages, like more than 500 (or perhaps, if it's 'light' packages, 1000). It should only see non-breaking mass-rebuild commits. That means it is not to be used for testing, and changes must have been well tested already. If the branch is already in a broken state, please refrain from adding extra new breakages.
|
||||
|
||||
### Staging-next branch {#submitting-changes-staging-next-branch}
|
||||
|
||||
|
||||
@ -1,5 +1,8 @@
|
||||
{ pkgs ? (import ../.. {}), nixpkgs ? { }}:
|
||||
let
|
||||
inherit (pkgs) lib;
|
||||
inherit (lib) hasPrefix removePrefix;
|
||||
|
||||
locationsXml = import ./lib-function-locations.nix { inherit pkgs nixpkgs; };
|
||||
functionDocs = import ./lib-function-docs.nix { inherit locationsXml pkgs; };
|
||||
version = pkgs.lib.version;
|
||||
@ -23,6 +26,26 @@ let
|
||||
<xsl:import href="${./parameters.xml}"/>
|
||||
</xsl:stylesheet>
|
||||
'';
|
||||
|
||||
# NB: This file describes the Nixpkgs manual, which happens to use module
|
||||
# docs infra originally developed for NixOS.
|
||||
optionsDoc = pkgs.nixosOptionsDoc {
|
||||
inherit (pkgs.lib.evalModules { modules = [ ../../pkgs/top-level/config.nix ]; }) options;
|
||||
documentType = "none";
|
||||
transformOptions = opt:
|
||||
opt // {
|
||||
declarations =
|
||||
map
|
||||
(decl:
|
||||
if hasPrefix (toString ../..) (toString decl)
|
||||
then
|
||||
let subpath = removePrefix "/" (removePrefix (toString ../..) (toString decl));
|
||||
in { url = "https://github.com/NixOS/nixpkgs/blob/master/${subpath}"; name = subpath; }
|
||||
else decl)
|
||||
opt.declarations;
|
||||
};
|
||||
};
|
||||
|
||||
in pkgs.runCommand "doc-support" {}
|
||||
''
|
||||
mkdir result
|
||||
@ -30,6 +53,7 @@ in pkgs.runCommand "doc-support" {}
|
||||
cd result
|
||||
ln -s ${locationsXml} ./function-locations.xml
|
||||
ln -s ${functionDocs} ./function-docs
|
||||
ln -s ${optionsDoc.optionsDocBook} ./config-options.docbook.xml
|
||||
|
||||
ln -s ${pkgs.docbook5}/xml/rng/docbook/docbook.rng ./docbook.rng
|
||||
ln -s ${pkgs.docbook_xsl_ns}/xml/xsl ./xsl
|
||||
|
||||
@ -29,10 +29,15 @@ The recommended way of defining a derivation for a Coq library, is to use the `c
|
||||
* `releaseRev` (optional, defaults to `(v: v)`), provides a default mapping from release names to revision hashes/branch names/tags,
|
||||
* `displayVersion` (optional), provides a way to alter the computation of `name` from `pname`, by explaining how to display version numbers,
|
||||
* `namePrefix` (optional, defaults to `[ "coq" ]`), provides a way to alter the computation of `name` from `pname`, by explaining which dependencies must occur in `name`,
|
||||
* `extraNativeBuildInputs` (optional), by default `nativeBuildInputs` just contains `coq`, this allows to add more native build inputs, `nativeBuildInputs` are executables and `buildInputs` are libraries and dependencies,
|
||||
* `extraBuildInputs` (optional), this allows to add more build inputs,
|
||||
* `mlPlugin` (optional, defaults to `false`). Some extensions (plugins) might require OCaml and sometimes other OCaml packages. Standard dependencies can be added by setting the current option to `true`. For a finer grain control, the `coq.ocamlPackages` attribute can be used in `extraBuildInputs` to depend on the same package set Coq was built against.
|
||||
* `useDune2ifVersion` (optional, default to `(x: false)` uses Dune2 to build the package if the provided predicate evaluates to true on the version, e.g. `useDune2if = versions.isGe "1.1"` will use dune if the version of the package is greater or equal to `"1.1"`,
|
||||
* `nativeBuildInputs` (optional), is a list of executables that are required to build the current derivation, in addition to the default ones (namely `which`, `dune` and `ocaml` depending on whether `useDune2`, `useDune2ifVersion` and `mlPlugin` are set).
|
||||
* `extraNativeBuildInputs` (optional, deprecated), an additional list of derivation to add to `nativeBuildInputs`,
|
||||
* `overrideNativeBuildInputs` (optional) replaces the default list of derivation to which `nativeBuildInputs` and `extraNativeBuildInputs` adds extra elements,
|
||||
* `buildInputs` (optional), is a list of libraries and dependencies that are required to build and run the current derivation, in addition to the default one `[ coq ]`,
|
||||
* `extraBuildInputs` (optional, deprecated), an additional list of derivation to add to `buildInputs`,
|
||||
* `overrideBuildInputs` (optional) replaces the default list of derivation to which `buildInputs` and `extraBuildInputs` adds extras elements,
|
||||
* `propagatedBuildInputs` (optional) is passed as is to `mkDerivation`, we recommend to use this for Coq libraries and Coq plugin dependencies, as this makes sure the paths of the compiled libraries and plugins will always be added to the build environements of subsequent derivation, which is necessary for Coq packages to work correctly,
|
||||
* `mlPlugin` (optional, defaults to `false`). Some extensions (plugins) might require OCaml and sometimes other OCaml packages. Standard dependencies can be added by setting the current option to `true`. For a finer grain control, the `coq.ocamlPackages` attribute can be used in `nativeBuildInputs`, `buildInputs`, and `propagatedBuildInputs` to depend on the same package set Coq was built against.
|
||||
* `useDune2ifVersion` (optional, default to `(x: false)` uses Dune2 to build the package if the provided predicate evaluates to true on the version, e.g. `useDune2ifVersion = versions.isGe "1.1"` will use dune if the version of the package is greater or equal to `"1.1"`,
|
||||
* `useDune2` (optional, defaults to `false`) uses Dune2 to build the package if set to true, the presence of this attribute overrides the behavior of the previous one.
|
||||
* `opam-name` (optional, defaults to concatenating with a dash separator the components of `namePrefix` and `pname`), name of the Dune package to build.
|
||||
* `enableParallelBuilding` (optional, defaults to `true`), since it is activated by default, we provide a way to disable it.
|
||||
|
||||
@ -72,7 +72,7 @@ The `dotnetCorePackages.sdk` contains both a runtime and the full sdk of a given
|
||||
To package Dotnet applications, you can use `buildDotnetModule`. This has similar arguments to `stdenv.mkDerivation`, with the following additions:
|
||||
|
||||
* `projectFile` has to be used for specifying the dotnet project file relative to the source root. These usually have `.sln` or `.csproj` file extensions. This can be an array of multiple projects as well.
|
||||
* `nugetDeps` has to be used to specify the NuGet dependency file. Unfortunately, these cannot be deterministically fetched without a lockfile. A script to fetch these is available as `passthru.fetch-deps`. This file can also be generated manually using `nuget-to-nix` tool, which is available in nixpkgs.
|
||||
* `nugetDeps` takes either a path to a `deps.nix` file, or a derivation. The `deps.nix` file can be generated using the script attached to `passthru.fetch-deps`. This file can also be generated manually using `nuget-to-nix` tool, which is available in nixpkgs. If the argument is a derivation, it will be used directly and assume it has the same output as `mkNugetDeps`.
|
||||
* `packNupkg` is used to pack project as a `nupkg`, and installs it to `$out/share`. If set to `true`, the derivation can be used as a dependency for another dotnet project by adding it to `projectReferences`.
|
||||
* `projectReferences` can be used to resolve `ProjectReference` project items. Referenced projects can be packed with `buildDotnetModule` by setting the `packNupkg = true` attribute and passing a list of derivations to `projectReferences`. Since we are sharing referenced projects as NuGets they must be added to csproj/fsproj files as `PackageReference` as well.
|
||||
For example, your project has a local dependency:
|
||||
|
||||
@ -8,19 +8,16 @@ The various tools available will be listed in the [tools-overview](#javascript-t
|
||||
|
||||
## Getting unstuck / finding code examples
|
||||
|
||||
If you find you are lacking inspiration for packing javascript applications, the links below might prove useful.
|
||||
Searching online for prior art can be helpful if you are running into solved problems.
|
||||
If you find you are lacking inspiration for packing javascript applications, the links below might prove useful. Searching online for prior art can be helpful if you are running into solved problems.
|
||||
|
||||
### Github
|
||||
|
||||
- Searching Nix files for `mkYarnPackage`: <https://github.com/search?q=mkYarnPackage+language%3ANix&type=code>
|
||||
|
||||
- Searching just `flake.nix` files for `mkYarnPackage`: <https://github.com/search?q=mkYarnPackage+filename%3Aflake.nix&type=code>
|
||||
|
||||
### Gitlab
|
||||
|
||||
- Searching Nix files for `mkYarnPackage`: <https://gitlab.com/search?scope=blobs&search=mkYarnPackage+extension%3Anix>
|
||||
|
||||
- Searching just `flake.nix` files for `mkYarnPackage`: <https://gitlab.com/search?scope=blobs&search=mkYarnPackage+filename%3Aflake.nix>
|
||||
|
||||
## Tools overview {#javascript-tools-overview}
|
||||
@ -35,109 +32,107 @@ It is often not documented which node version is used upstream, but if it is, tr
|
||||
|
||||
This can be a problem if upstream is using the latest and greatest and you are trying to use an earlier version of node. Some cryptic errors regarding V8 may appear.
|
||||
|
||||
An exception to this:
|
||||
|
||||
### Try to respect the package manager originally used by upstream (and use the upstream lock file) {#javascript-upstream-package-manager}
|
||||
|
||||
A lock file (package-lock.json, yarn.lock...) is supposed to make reproducible installations of node_modules for each tool.
|
||||
|
||||
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. An example of problems that could arise can be found [here](https://github.com/NixOS/nixpkgs/pull/126629). Upstream uses npm, but this is an attempt to package it with yarn2nix (that uses yarn.lock)
|
||||
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. 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.
|
||||
|
||||
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
|
||||
- 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.
|
||||
- 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.
|
||||
- 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`.
|
||||
|
||||
### Try to use upstream package.json {#javascript-upstream-package-json}
|
||||
|
||||
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 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:
|
||||
- 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 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,
|
||||
|
||||
```Shell
|
||||
yarn build:ui
|
||||
yarn build:server
|
||||
# OR
|
||||
npm run build:ui
|
||||
npm run build:server
|
||||
```
|
||||
```sh
|
||||
yarn build:ui
|
||||
yarn build:server
|
||||
# OR
|
||||
npm run build:ui
|
||||
npm run build:server
|
||||
```
|
||||
|
||||
when you need to override a package.json. It's nice to use the one from the upstream src and do some explicit override. Here is an example.
|
||||
when you need to override a package.json. It's nice to use the one from the upstream source and do some explicit override. Here is an example:
|
||||
|
||||
```nix
|
||||
patchedPackageJSON = final.runCommand "package.json" { } ''
|
||||
${jq}/bin/jq '.version = "0.4.0" |
|
||||
.devDependencies."@jsdoc/cli" = "^0.2.5"
|
||||
${sonar-src}/package.json > $out
|
||||
'';
|
||||
```
|
||||
```nix
|
||||
patchedPackageJSON = final.runCommand "package.json" { } ''
|
||||
${jq}/bin/jq '.version = "0.4.0" |
|
||||
.devDependencies."@jsdoc/cli" = "^0.2.5"
|
||||
${sonar-src}/package.json > $out
|
||||
'';
|
||||
```
|
||||
|
||||
you will still need to commit the modified version of the lock files, but at least the overrides are explicit for everyone to see.
|
||||
You will still need to commit the modified version of the lock files, but at least the overrides are explicit for everyone to see.
|
||||
|
||||
### Using node_modules directly {#javascript-using-node_modules}
|
||||
|
||||
each tool has an abstraction to just build the node_modules (dependencies) directory. you can always use the stdenv.mkDerivation with the node_modules to build the package (symlink the node_modules directory and then use the package build command). the node_modules abstraction can be also used to build some web framework frontends. For an example of this see how [plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix) is built. mkYarnModules to make the derivation containing node_modules. Then when building the frontend you can just symlink the node_modules directory
|
||||
Each tool has an abstraction to just build the node_modules (dependencies) directory. You can always use the `stdenv.mkDerivation` with the node_modules to build the package (symlink the node_modules directory and then use the package build command). The node_modules abstraction can be also used to build some web framework frontends. For an example of this see how [plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix) is built. `mkYarnModules` to make the derivation containing node_modules. Then when building the frontend you can just symlink the node_modules directory.
|
||||
|
||||
## Javascript packages inside nixpkgs {#javascript-packages-nixpkgs}
|
||||
|
||||
The `pkgs/development/node-packages` folder contains a generated collection of
|
||||
[NPM packages](https://npmjs.com/) that can be installed with the Nix package
|
||||
manager.
|
||||
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. Libraries should only be added to the
|
||||
package set if there is a non-NPM package that requires it.
|
||||
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.
|
||||
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.
|
||||
|
||||
The package set provides support for the official stable Node.js versions.
|
||||
The latest stable LTS release in `nodePackages`, as well as the latest stable
|
||||
Current release in `nodePackages_latest`.
|
||||
The package set provides support for the official stable Node.js versions. The latest stable LTS release in `nodePackages`, as well as the latest stable current release in `nodePackages_latest`.
|
||||
|
||||
If your package uses native addons, you need to examine what kind of native
|
||||
build system it uses. Here are some examples:
|
||||
If your package uses native addons, you need to examine what kind of native build system it uses. Here are some examples:
|
||||
|
||||
- `node-gyp`
|
||||
- `node-gyp-builder`
|
||||
- `node-pre-gyp`
|
||||
|
||||
After you have identified the correct system, you need to override your package
|
||||
expression while adding in build system as a build input. For example, `dat`
|
||||
requires `node-gyp-build`, so [we override](https://github.com/NixOS/nixpkgs/blob/32f5e5da4a1b3f0595527f5195ac3a91451e9b56/pkgs/development/node-packages/default.nix#L37-L40) its expression in [`default.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/default.nix):
|
||||
After you have identified the correct system, you need to override your package expression while adding in build system as a build input. For example, `dat` requires `node-gyp-build`, so we override its expression in [pkgs/development/node-packages/overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/overrides.nix):
|
||||
|
||||
```nix
|
||||
dat = super.dat.override {
|
||||
buildInputs = [ self.node-gyp-build pkgs.libtool pkgs.autoconf pkgs.automake ];
|
||||
meta.broken = since "12";
|
||||
};
|
||||
dat = prev.dat.override (oldAttrs: {
|
||||
buildInputs = [ final.node-gyp-build pkgs.libtool pkgs.autoconf pkgs.automake ];
|
||||
meta = oldAttrs.meta // { broken = since "12"; };
|
||||
});
|
||||
```
|
||||
|
||||
### Adding and Updating Javascript packages in nixpkgs
|
||||
|
||||
To add a package from NPM to nixpkgs:
|
||||
|
||||
1. Modify `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: `./pkgs/development/node-packages/generate.sh`.
|
||||
3. Build your new package to test your changes:
|
||||
`cd /path/to/nixpkgs && nix-build -A nodePackages.<new-or-updated-package>`.
|
||||
To build against the latest stable Current Node.js version (e.g. 14.x):
|
||||
`nix-build -A nodePackages_latest.<new-or-updated-package>`
|
||||
4. Add and commit all modified and generated files.
|
||||
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:
|
||||
|
||||
For more information about the generation process, consult the
|
||||
[README.md](https://github.com/svanderburg/node2nix) file of the `node2nix`
|
||||
tool.
|
||||
```sh
|
||||
./pkgs/development/node-packages/generate.sh
|
||||
```
|
||||
|
||||
3. Build your new package to test your changes:
|
||||
|
||||
```sh
|
||||
nix-build -A nodePackages.<new-or-updated-package>
|
||||
```
|
||||
|
||||
To build against the latest stable Current Node.js version (e.g. 18.x):
|
||||
|
||||
```sh
|
||||
nix-build -A nodePackages_latest.<new-or-updated-package>
|
||||
```
|
||||
|
||||
If the package doesn't build, you may need to add an override as explained above.
|
||||
4. If the package's name doesn't match any of the executables it provides, add an entry in [pkgs/development/node-packages/main-programs.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/main-programs.nix). This will be the case for all scoped packages, e.g., `@angular/cli`.
|
||||
5. Add and commit all modified and generated files.
|
||||
|
||||
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:
|
||||
|
||||
@ -148,10 +143,11 @@ To update NPM packages in nixpkgs, run the same `generate.sh` script:
|
||||
#### Git protocol error
|
||||
|
||||
Some packages may have Git dependencies from GitHub specified with `git://`.
|
||||
GitHub has
|
||||
[disabled unecrypted Git connections](https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git),
|
||||
so you may see the following error when running the generate script:
|
||||
`The unauthenticated git protocol on port 9418 is no longer supported`.
|
||||
GitHub has [disabled unecrypted Git connections](https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git), so you may see the following error when running the generate script:
|
||||
|
||||
```
|
||||
The unauthenticated git protocol on port 9418 is no longer supported
|
||||
```
|
||||
|
||||
Use the following Git configuration to resolve the issue:
|
||||
|
||||
@ -165,34 +161,33 @@ git config --global url."https://github.com/".insteadOf git://github.com/
|
||||
|
||||
#### Preparation {#javascript-node2nix-preparation}
|
||||
|
||||
you will need to generate a nix expression for the dependencies
|
||||
You will need to generate a Nix expression for the dependencies. Don't forget the `-l package-lock.json` if there is a lock file. Most probably you will need the `--development` to include the `devDependencies`
|
||||
|
||||
- don't forget the `-l package-lock.json` if there is a lock file
|
||||
- Most probably you will need the `--development` to include the `devDependencies`
|
||||
So the command will most likely be:
|
||||
```sh
|
||||
node2nix --development -l package-lock.json
|
||||
```
|
||||
|
||||
so the command will most likely be
|
||||
`node2nix --development -l package-lock.json`
|
||||
|
||||
[link to the doc in the repo](https://github.com/svanderburg/node2nix)
|
||||
See `node2nix` [docs](https://github.com/svanderburg/node2nix) for more info.
|
||||
|
||||
#### Pitfalls {#javascript-node2nix-pitfalls}
|
||||
|
||||
- if upstream package.json does not have a "version" attribute, node2nix will crash. You will need to add it like shown in [the package.json section](#javascript-upstream-package-json)
|
||||
- node2nix has some [bugs](https://github.com/svanderburg/node2nix/issues/238). related to working with lock files from npm distributed with nodejs-16_x
|
||||
- node2nix does not like missing packages from npm. If you see something like `Cannot resolve version: vue-loader-v16@undefined` then you might want to try another tool. The package might have been pulled off of npm.
|
||||
- If upstream package.json does not have a "version" attribute, `node2nix` will crash. You will need to add it like shown in [the package.json section](#javascript-upstream-package-json).
|
||||
- `node2nix` has some [bugs](https://github.com/svanderburg/node2nix/issues/238) related to working with lock files from NPM distributed with `nodejs-16_x`.
|
||||
- `node2nix` does not like missing packages from NPM. If you see something like `Cannot resolve version: vue-loader-v16@undefined` then you might want to try another tool. The package might have been pulled off of NPM.
|
||||
|
||||
### yarn2nix {#javascript-yarn2nix}
|
||||
|
||||
#### Preparation {#javascript-yarn2nix-preparation}
|
||||
|
||||
you will need at least a yarn.lock and yarn.nix file
|
||||
You will need at least a yarn.lock and yarn.nix file.
|
||||
|
||||
- generate a yarn.lock in upstream if it is not already there
|
||||
- `yarn2nix > yarn.nix` will generate the dependencies in a nix format
|
||||
- Generate a yarn.lock in upstream if it is not already there.
|
||||
- `yarn2nix > yarn.nix` will generate the dependencies in a Nix format.
|
||||
|
||||
#### mkYarnPackage {#javascript-yarn2nix-mkYarnPackage}
|
||||
|
||||
this will by default try to generate a binary. For package only generating static assets (Svelte, Vue, React...), 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
|
||||
This will by default try to generate a binary. For package only generating static assets (Svelte, Vue, React...), 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:
|
||||
|
||||
```nix
|
||||
buildPhase = ''
|
||||
@ -200,14 +195,13 @@ buildPhase = ''
|
||||
'';
|
||||
```
|
||||
|
||||
The dist phase is also trying to build a binary, the only way to override it is with
|
||||
The dist phase is also trying to build a binary, the only way to override it is with:
|
||||
|
||||
```nix
|
||||
distPhase = "true";
|
||||
```
|
||||
|
||||
the configure phase can sometimes fail because it tries to be too clever.
|
||||
One common override is
|
||||
The configure phase can sometimes fail because it tries to be too clever. One common override is:
|
||||
|
||||
```nix
|
||||
configurePhase = "ln -s $node_modules node_modules";
|
||||
@ -215,13 +209,17 @@ configurePhase = "ln -s $node_modules node_modules";
|
||||
|
||||
#### mkYarnModules {#javascript-yarn2nix-mkYarnModules}
|
||||
|
||||
this will generate a derivation including the node_modules. If you have to build a derivation for an integrated web framework (rails, phoenix..), this is probably the easiest way. [Plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix#L39) offers a good example of how to do this.
|
||||
This will generate a derivation including the node_modules. If you have to build a derivation for an integrated web framework (rails, phoenix..), this is probably the easiest way. [Plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix#L39) offers a good example of how to do this.
|
||||
|
||||
#### Overriding dependency behavior
|
||||
|
||||
In the `mkYarnPackage` record the property `pkgConfig` can be used to override packages when you encounter problems building.
|
||||
|
||||
For instance, say your package is throwing errors when trying to invoke node-sass: `ENOENT: no such file or directory, scandir '/build/source/node_modules/node-sass/vendor'`
|
||||
For instance, say your package is throwing errors when trying to invoke node-sass:
|
||||
|
||||
```
|
||||
ENOENT: no such file or directory, scandir '/build/source/node_modules/node-sass/vendor'
|
||||
```
|
||||
|
||||
To fix this we will specify different versions of build inputs to use, as well as some post install steps to get the software built the way we want:
|
||||
|
||||
@ -241,9 +239,8 @@ mkYarnPackage rec {
|
||||
|
||||
#### Pitfalls {#javascript-yarn2nix-pitfalls}
|
||||
|
||||
- if version is missing from upstream package.json, yarn will silently install nothing. In that case, you will need to override package.json as shown in the [package.json section](#javascript-upstream-package-json)
|
||||
|
||||
- having trouble with node-gyp? Try adding these lines to the `yarnPreBuild` steps:
|
||||
- If version is missing from upstream package.json, yarn will silently install nothing. In that case, you will need to override package.json as shown in the [package.json section](#javascript-upstream-package-json)
|
||||
- Having trouble with `node-gyp`? Try adding these lines to the `yarnPreBuild` steps:
|
||||
|
||||
```nix
|
||||
yarnPreBuild = ''
|
||||
@ -259,20 +256,20 @@ mkYarnPackage rec {
|
||||
|
||||
## Outside of nixpkgs {#javascript-outside-nixpkgs}
|
||||
|
||||
There are some other options available that can't be used inside nixpkgs. Those other options are written in nix. Importing them in nixpkgs will require moving the source code into nixpkgs. Using [Import From Derivation](https://nixos.wiki/wiki/Import_From_Derivation) is not allowed in hydra at present. If you are packaging something outside nixpkgs, those can be considered
|
||||
There are some other options available that can't be used inside nixpkgs. Those other options are written in Nix. Importing them in nixpkgs will require moving the source code into nixpkgs. Using [Import From Derivation](https://nixos.wiki/wiki/Import_From_Derivation) is not allowed in Hydra at present. If you are packaging something outside nixpkgs, those can be considered
|
||||
|
||||
### npmlock2nix {#javascript-npmlock2nix}
|
||||
|
||||
[npmlock2nix](https://github.com/nix-community/npmlock2nix) aims at building node_modules without code generation. It hasn't reached v1 yet, the api might be subject to change.
|
||||
[npmlock2nix](https://github.com/nix-community/npmlock2nix) aims at building node_modules without code generation. It hasn't reached v1 yet, the API might be subject to change.
|
||||
|
||||
#### Pitfalls {#javascript-npmlock2nix-pitfalls}
|
||||
|
||||
- there are some [problems with npm v7](https://github.com/tweag/npmlock2nix/issues/45).
|
||||
There are some [problems with npm v7](https://github.com/tweag/npmlock2nix/issues/45).
|
||||
|
||||
### nix-npm-buildpackage {#javascript-nix-npm-buildpackage}
|
||||
|
||||
[nix-npm-buildpackage](https://github.com/serokell/nix-npm-buildpackage) aims at building node_modules without code generation. It hasn't reached v1 yet, the api might change. It supports both package-lock.json and yarn.lock.
|
||||
[nix-npm-buildpackage](https://github.com/serokell/nix-npm-buildpackage) aims at building node_modules without code generation. It hasn't reached v1 yet, the API might change. It supports both package-lock.json and yarn.lock.
|
||||
|
||||
#### Pitfalls {#javascript-nix-npm-buildpackage-pitfalls}
|
||||
|
||||
- there are some [problems with npm v7](https://github.com/serokell/nix-npm-buildpackage/issues/33).
|
||||
There are some [problems with npm v7](https://github.com/serokell/nix-npm-buildpackage/issues/33).
|
||||
|
||||
@ -9,7 +9,7 @@ wide variety of extensions and libraries available.
|
||||
|
||||
The different versions of PHP that nixpkgs provides are located under
|
||||
attributes named based on major and minor version number; e.g.,
|
||||
`php74` is PHP 7.4.
|
||||
`php81` is PHP 8.1.
|
||||
|
||||
Only versions of PHP that are supported by upstream for the entirety
|
||||
of a given NixOS release will be included in that release of
|
||||
@ -23,7 +23,7 @@ NixOS - not necessarily the latest major release from upstream.
|
||||
All available PHP attributes are wrappers around their respective
|
||||
binary PHP package and provide commonly used extensions this way. The
|
||||
real PHP 7.4 package, i.e. the unwrapped one, is available as
|
||||
`php74.unwrapped`; see the next section for more details.
|
||||
`php81.unwrapped`; see the next section for more details.
|
||||
|
||||
Interactive tools built on PHP are put in `php.packages`; composer is
|
||||
for example available at `php.packages.composer`.
|
||||
|
||||
@ -8,9 +8,9 @@
|
||||
|
||||
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.9. The attribute `python` refers to
|
||||
interpreter, which is currently CPython 3.10. The attribute `python` refers to
|
||||
CPython 2.7 for backwards-compatibility. It is also possible to refer to
|
||||
specific versions, e.g. `python38` refers to CPython 3.8, and `pypy` refers to
|
||||
specific versions, e.g. `python39` refers to CPython 3.9, and `pypy` refers to
|
||||
the default PyPy interpreter.
|
||||
|
||||
Python is used a lot, and in different ways. This affects also how it is
|
||||
@ -26,10 +26,10 @@ however, are in separate sets, with one set per interpreter version.
|
||||
The interpreters have several common attributes. One of these attributes is
|
||||
`pkgs`, which is a package set of Python libraries for this specific
|
||||
interpreter. E.g., the `toolz` package corresponding to the default interpreter
|
||||
is `python.pkgs.toolz`, and the CPython 3.8 version is `python38.pkgs.toolz`.
|
||||
is `python.pkgs.toolz`, and the CPython 3.9 version is `python39.pkgs.toolz`.
|
||||
The main package set contains aliases to these package sets, e.g.
|
||||
`pythonPackages` refers to `python.pkgs` and `python38Packages` to
|
||||
`python38.pkgs`.
|
||||
`pythonPackages` refers to `python.pkgs` and `python39Packages` to
|
||||
`python39.pkgs`.
|
||||
|
||||
#### Installing Python and packages {#installing-python-and-packages}
|
||||
|
||||
@ -54,7 +54,7 @@ with `python.buildEnv` or `python.withPackages` where the interpreter and other
|
||||
executables are wrapped to be able to find each other and all of the modules.
|
||||
|
||||
In the following examples we will start by creating a simple, ad-hoc environment
|
||||
with a nix-shell that has `numpy` and `toolz` in Python 3.8; then we will create
|
||||
with a nix-shell that has `numpy` and `toolz` in Python 3.9; then we will create
|
||||
a re-usable environment in a single-file Python script; then we will create a
|
||||
full Python environment for development with this same environment.
|
||||
|
||||
@ -70,10 +70,10 @@ temporary shell session with a Python and a *precise* list of packages (plus
|
||||
their runtime dependencies), with no other Python packages in the Python
|
||||
interpreter's scope.
|
||||
|
||||
To create a Python 3.8 session with `numpy` and `toolz` available, run:
|
||||
To create a Python 3.9 session with `numpy` and `toolz` available, run:
|
||||
|
||||
```sh
|
||||
$ nix-shell -p 'python38.withPackages(ps: with ps; [ numpy toolz ])'
|
||||
$ nix-shell -p 'python39.withPackages(ps: with ps; [ numpy toolz ])'
|
||||
```
|
||||
|
||||
By default `nix-shell` will start a `bash` session with this interpreter in our
|
||||
@ -81,8 +81,8 @@ By default `nix-shell` will start a `bash` session with this interpreter in our
|
||||
|
||||
```Python console
|
||||
[nix-shell:~/src/nixpkgs]$ python3
|
||||
Python 3.8.1 (default, Dec 18 2019, 19:06:26)
|
||||
[GCC 9.2.0] on linux
|
||||
Python 3.9.12 (main, Mar 23 2022, 21:36:19)
|
||||
[GCC 11.3.0] on linux
|
||||
Type "help", "copyright", "credits" or "license" for more information.
|
||||
>>> import numpy; import toolz
|
||||
```
|
||||
@ -102,13 +102,16 @@ will still get 1 wrapped Python interpreter. We can start the interpreter
|
||||
directly like so:
|
||||
|
||||
```sh
|
||||
$ nix-shell -p 'python38.withPackages(ps: with ps; [ numpy toolz requests ])' --run python3
|
||||
these derivations will be built:
|
||||
/nix/store/xbdsrqrsfa1yva5s7pzsra8k08gxlbz1-python3-3.8.1-env.drv
|
||||
building '/nix/store/xbdsrqrsfa1yva5s7pzsra8k08gxlbz1-python3-3.8.1-env.drv'...
|
||||
created 277 symlinks in user environment
|
||||
Python 3.8.1 (default, Dec 18 2019, 19:06:26)
|
||||
[GCC 9.2.0] on linux
|
||||
$ nix-shell -p "python39.withPackages (ps: with ps; [ numpy toolz requests ])" --run python3
|
||||
this derivation will be built:
|
||||
/nix/store/mpn7k6bkjl41fm51342rafaqfsl10qs4-python3-3.9.12-env.drv
|
||||
this path will be fetched (0.09 MiB download, 0.41 MiB unpacked):
|
||||
/nix/store/5gaiacnzi096b6prc6aa1pwrhncmhc8b-python3.9-toolz-0.11.2
|
||||
copying path '/nix/store/5gaiacnzi096b6prc6aa1pwrhncmhc8b-python3.9-toolz-0.11.2' from 'https://cache.nixos.org'...
|
||||
building '/nix/store/mpn7k6bkjl41fm51342rafaqfsl10qs4-python3-3.9.12-env.drv'...
|
||||
created 279 symlinks in user environment
|
||||
Python 3.9.12 (main, Mar 23 2022, 21:36:19)
|
||||
[GCC 11.3.0] on linux
|
||||
Type "help", "copyright", "credits" or "license" for more information.
|
||||
>>> import requests
|
||||
>>>
|
||||
@ -147,7 +150,7 @@ Executing this script requires a `python3` that has `numpy`. Using what we learn
|
||||
in the previous section, we could startup a shell and just run it like so:
|
||||
|
||||
```ShellSession
|
||||
$ nix-shell -p 'python38.withPackages(ps: with ps; [ numpy ])' --run 'python3 foo.py'
|
||||
$ nix-shell -p 'python39.withPackages(ps: with ps; [ numpy ])' --run 'python3 foo.py'
|
||||
The dot product of [1 2] and [3 4] is: 11
|
||||
```
|
||||
|
||||
@ -210,12 +213,12 @@ create a single script with Python dependencies, but in the course of normal
|
||||
development we're usually working in an entire package repository.
|
||||
|
||||
As explained in the Nix manual, `nix-shell` can also load an expression from a
|
||||
`.nix` file. Say we want to have Python 3.8, `numpy` and `toolz`, like before,
|
||||
`.nix` file. Say we want to have Python 3.9, `numpy` and `toolz`, like before,
|
||||
in an environment. We can add a `shell.nix` file describing our dependencies:
|
||||
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
(python38.withPackages (ps: [ps.numpy ps.toolz])).env
|
||||
(python39.withPackages (ps: [ps.numpy ps.toolz])).env
|
||||
```
|
||||
|
||||
And then at the command line, just typing `nix-shell` produces the same
|
||||
@ -229,7 +232,7 @@ What's happening here?
|
||||
imports the `<nixpkgs>` function, `{}` calls it and the `with` statement
|
||||
brings all attributes of `nixpkgs` in the local scope. These attributes form
|
||||
the main package set.
|
||||
2. Then we create a Python 3.8 environment with the `withPackages` function, as before.
|
||||
2. Then we create a Python 3.9 environment with the `withPackages` function, as before.
|
||||
3. The `withPackages` function expects us to provide a function as an argument
|
||||
that takes the set of all Python packages and returns a list of packages to
|
||||
include in the environment. Here, we select the packages `numpy` and `toolz`
|
||||
@ -240,7 +243,7 @@ To combine this with `mkShell` you can:
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
let
|
||||
pythonEnv = python38.withPackages (ps: [
|
||||
pythonEnv = python39.withPackages (ps: [
|
||||
ps.numpy
|
||||
ps.toolz
|
||||
]);
|
||||
@ -288,7 +291,7 @@ self: super: {
|
||||
ps: with ps; [
|
||||
pyflakes
|
||||
pytest
|
||||
python-language-server
|
||||
black
|
||||
]
|
||||
))
|
||||
|
||||
@ -378,8 +381,8 @@ information. The output of the function is a derivation.
|
||||
|
||||
An expression for `toolz` can be found in the Nixpkgs repository. As explained
|
||||
in the introduction of this Python section, a derivation of `toolz` is available
|
||||
for each interpreter version, e.g. `python38.pkgs.toolz` refers to the `toolz`
|
||||
derivation corresponding to the CPython 3.8 interpreter.
|
||||
for each interpreter version, e.g. `python39.pkgs.toolz` refers to the `toolz`
|
||||
derivation corresponding to the CPython 3.9 interpreter.
|
||||
|
||||
The above example works when you're directly working on
|
||||
`pkgs/top-level/python-packages.nix` in the Nixpkgs repository. Often though,
|
||||
@ -392,11 +395,11 @@ and adds it along with a `numpy` package to a Python environment.
|
||||
with import <nixpkgs> {};
|
||||
|
||||
( let
|
||||
my_toolz = python38.pkgs.buildPythonPackage rec {
|
||||
my_toolz = python39.pkgs.buildPythonPackage rec {
|
||||
pname = "toolz";
|
||||
version = "0.10.0";
|
||||
|
||||
src = python38.pkgs.fetchPypi {
|
||||
src = python39.pkgs.fetchPypi {
|
||||
inherit pname version;
|
||||
sha256 = "08fdd5ef7c96480ad11c12d472de21acd32359996f69a5259299b540feba4560";
|
||||
};
|
||||
@ -414,7 +417,7 @@ with import <nixpkgs> {};
|
||||
```
|
||||
|
||||
Executing `nix-shell` will result in an environment in which you can use
|
||||
Python 3.8 and the `toolz` package. As you can see we had to explicitly mention
|
||||
Python 3.9 and the `toolz` package. As you can see we had to explicitly mention
|
||||
for which Python version we want to build a package.
|
||||
|
||||
So, what did we do here? Well, we took the Nix expression that we used earlier
|
||||
@ -663,6 +666,70 @@ However, this is done in it's own phase, and not dependent on whether `doCheck =
|
||||
This can also be useful in verifying that the package doesn't assume commonly
|
||||
present packages (e.g. `setuptools`)
|
||||
|
||||
#### Using pythonRelaxDepsHook {#using-pythonrelaxdepshook}
|
||||
|
||||
It is common for upstream to specify a range of versions for its package
|
||||
dependencies. This makes sense, since it ensures that the package will be built
|
||||
with a subset of packages that is well tested. However, this commonly causes
|
||||
issues when packaging in Nixpkgs, because the dependencies that this package
|
||||
may need are too new or old for the package to build correctly. We also cannot
|
||||
package multiple versions of the same package since this may cause conflicts
|
||||
in `PYTHONPATH`.
|
||||
|
||||
One way to side step this issue is to relax the dependencies. This can be done
|
||||
by either removing the package version range or by removing the package
|
||||
declaration entirely. This can be done using the `pythonRelaxDepsHook` hook. For
|
||||
example, given the following `requirements.txt` file:
|
||||
|
||||
```
|
||||
pkg1<1.0
|
||||
pkg2
|
||||
pkg3>=1.0,<=2.0
|
||||
```
|
||||
|
||||
we can do:
|
||||
|
||||
```
|
||||
nativeBuildInputs = [ pythonRelaxDepsHook ];
|
||||
pythonRelaxDeps = [ "pkg1" "pkg3" ];
|
||||
pythonRemoveDeps = [ "pkg2" ];
|
||||
```
|
||||
|
||||
which would result in the following `requirements.txt` file:
|
||||
|
||||
```
|
||||
pkg1
|
||||
pkg3
|
||||
```
|
||||
|
||||
Another option is to pass `true`, that will relax/remove all dependencies, for
|
||||
example:
|
||||
|
||||
```
|
||||
nativeBuildInputs = [ pythonRelaxDepsHook ];
|
||||
pythonRelaxDeps = true;
|
||||
```
|
||||
|
||||
which would result in the following `requirements.txt` file:
|
||||
|
||||
```
|
||||
pkg1
|
||||
pkg2
|
||||
pkg3
|
||||
```
|
||||
|
||||
In general you should always use `pythonRelaxDeps`, because `pythonRemoveDeps`
|
||||
will convert build errors in runtime errors. However `pythonRemoveDeps` may
|
||||
still be useful in exceptional cases, and also to remove dependencies wrongly
|
||||
declared by upstream (for example, declaring `black` as a runtime dependency
|
||||
instead of a dev dependency).
|
||||
|
||||
Keep in mind that while the examples above are done with `requirements.txt`,
|
||||
`pythonRelaxDepsHook` works by modifying the resulting wheel file, so it should
|
||||
work in any of the formats supported by `buildPythonPackage` currently,
|
||||
with the exception of `other` (see `format` in
|
||||
[`buildPythonPackage` parameters](#buildpythonpackage-parameters) for more details).
|
||||
|
||||
### Develop local package {#develop-local-package}
|
||||
|
||||
As a Python developer you're likely aware of [development mode](http://setuptools.readthedocs.io/en/latest/setuptools.html#development-mode)
|
||||
@ -678,7 +745,7 @@ If we create a `shell.nix` file which calls `buildPythonPackage`, and if `src`
|
||||
is a local source, and if the local source has a `setup.py`, then development
|
||||
mode is activated.
|
||||
|
||||
In the following example we create a simple environment that has a Python 3.8
|
||||
In the following example we create a simple environment that has a Python 3.9
|
||||
version of our package in it, as well as its dependencies and other packages we
|
||||
like to have in the environment, all specified with `propagatedBuildInputs`.
|
||||
Indeed, we can just add any package we like to have in our environment to
|
||||
@ -686,7 +753,7 @@ Indeed, we can just add any package we like to have in our environment to
|
||||
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
with python38Packages;
|
||||
with python39Packages;
|
||||
|
||||
buildPythonPackage rec {
|
||||
name = "mypackage";
|
||||
@ -764,9 +831,9 @@ and in this case the `python38` interpreter is automatically used.
|
||||
|
||||
### Interpreters {#interpreters}
|
||||
|
||||
Versions 2.7, 3.7, 3.8 and 3.9 of the CPython interpreter are available as
|
||||
respectively `python27`, `python37`, `python38` and `python39`. The
|
||||
aliases `python2` and `python3` correspond to respectively `python27` and
|
||||
Versions 2.7, 3.7, 3.8, 3.9 and 3.10 of the CPython interpreter are available
|
||||
as respectively `python27`, `python37`, `python38`, `python39` and `python310`.
|
||||
The aliases `python2` and `python3` correspond to respectively `python27` and
|
||||
`python39`. The attribute `python` maps to `python2`. The PyPy interpreters
|
||||
compatible with Python 2.7 and 3 are available as `pypy27` and `pypy3`, with
|
||||
aliases `pypy2` mapping to `pypy27` and `pypy` mapping to `pypy2`. The Nix
|
||||
@ -982,12 +1049,13 @@ in python.withPackages(ps: [ps.blaze])).env
|
||||
#### Optional extra dependencies
|
||||
|
||||
Some packages define optional dependencies for additional features. With
|
||||
`setuptools` this is called `extras_require` and `flit` calls it `extras-require`. A
|
||||
`setuptools` this is called `extras_require` and `flit` calls it
|
||||
`extras-require`, while PEP 621 calls these `optional-dependencies`. A
|
||||
method for supporting this is by declaring the extras of a package in its
|
||||
`passthru`, e.g. in case of the package `dask`
|
||||
|
||||
```nix
|
||||
passthru.extras-require = {
|
||||
passthru.optional-dependencies = {
|
||||
complete = [ distributed ];
|
||||
};
|
||||
```
|
||||
@ -997,7 +1065,7 @@ and letting the package requiring the extra add the list to its dependencies
|
||||
```nix
|
||||
propagatedBuildInputs = [
|
||||
...
|
||||
] ++ dask.extras-require.complete;
|
||||
] ++ dask.optional-dependencies.complete;
|
||||
```
|
||||
|
||||
Note this method is preferred over adding parameters to builders, as that can
|
||||
@ -1196,6 +1264,8 @@ are used in `buildPythonPackage`.
|
||||
to run commands only after venv is first created.
|
||||
- `wheelUnpackHook` to move a wheel to the correct folder so it can be installed
|
||||
with the `pipInstallHook`.
|
||||
- `pythonRelaxDepsHook` will relax Python dependencies restrictions for the package.
|
||||
See [example usage](#using-pythonrelaxdepshook).
|
||||
|
||||
### Development mode {#development-mode}
|
||||
|
||||
|
||||
@ -277,9 +277,6 @@ my-vim =
|
||||
copy paste output2 here
|
||||
];
|
||||
|
||||
# Pathogen would be
|
||||
# vimrcConfig.pathogen.knownPlugins = plugins; # plugins
|
||||
# vimrcConfig.pathogen.pluginNames = ["tlib"];
|
||||
};
|
||||
```
|
||||
|
||||
|
||||
@ -1,650 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<article xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink">
|
||||
<title>Nixpkgs Release Notes</title>
|
||||
<section xml:id="release-notes-0.14">
|
||||
<title>Release 0.14 (June 4, 2012)</title>
|
||||
|
||||
<para>
|
||||
In preparation for the switch from Subversion to Git, this release is mainly the prevent the Nixpkgs version number from going backwards. (This would happen because prerelease version numbers produced for the Git repository are lower than those for the Subversion repository.)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Since the last release, there have been thousands of changes and new packages by numerous contributors. For details, see the commit logs.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="release-notes-0.13">
|
||||
<title>Release 0.13 (February 5, 2010)</title>
|
||||
|
||||
<para>
|
||||
As always, there are many changes. Some of the most important updates are:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Glibc 2.9.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
GCC 4.3.3.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Linux 2.6.32.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
X.org 7.5.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
KDE 4.3.4.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="release-notes-0.12">
|
||||
<title>Release 0.12 (April 24, 2009)</title>
|
||||
|
||||
<para>
|
||||
There are way too many additions to Nixpkgs since the last release to list here: for example, the number of packages on Linux has increased from 1002 to 2159. However, some specific improvements are worth listing:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Nixpkgs now has a manual. In particular, it describes the standard build environment in detail.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Major new packages:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
KDE 4.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
TeXLive.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
VirtualBox.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
… and many others.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Important updates:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Glibc 2.7.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
GCC 4.2.4.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Linux 2.6.25 — 2.6.28.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Firefox 3.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
X.org 7.3.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Support for building derivations in a virtual machine, including RPM and Debian builds in automatically generated VM images. See <filename>pkgs/build-support/vm/default.nix</filename> for details.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Improved support for building Haskell packages.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following people contributed to this release: Andres Löh, Arie Middelkoop, Armijn Hemel, Eelco Dolstra, Lluís Batlle, Ludovic Courtès, Marc Weber, Mart Kolthof, Martin Bravenboer, Michael Raskin, Nicolas Pierron, Peter Simons, Pjotr Prins, Rob Vermaas, Sander van der Burg, Tobias Hammerschmidt, Valentin David, Wouter den Breejen and Yury G. Kudryashov. In addition, several people contributed patches on the <literal>nix-dev</literal> mailing list.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="release-notes-0.11">
|
||||
<title>Release 0.11 (September 11, 2007)</title>
|
||||
|
||||
<para>
|
||||
This release has the following improvements:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
The standard build environment (<literal>stdenv</literal>) is now pure on the <literal>x86_64-linux</literal> and <literal>powerpc-linux</literal> platforms, just as on <literal>i686-linux</literal>. (Purity means that building and using the standard environment has no dependencies outside of the Nix store. For instance, it doesn’t require an external C compiler such as <filename>/usr/bin/gcc</filename>.) Also, the statically linked binaries used in the bootstrap process are now automatically reproducible, making it easy to update the bootstrap tools and to add support for other Linux platforms. See <filename>pkgs/stdenv/linux/make-bootstrap-tools.nix</filename> for details.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Hook variables in the generic builder are now executed using the <function>eval</function> shell command. This has a major advantage: you can write hooks directly in Nix expressions. For instance, rather than writing a builder like this:
|
||||
<programlisting>
|
||||
source $stdenv/setup
|
||||
|
||||
postInstall=postInstall
|
||||
postInstall() {
|
||||
ln -sf gzip $out/bin/gunzip
|
||||
ln -sf gzip $out/bin/zcat
|
||||
}
|
||||
|
||||
genericBuild</programlisting>
|
||||
(the <literal>gzip</literal> builder), you can just add this attribute to the derivation:
|
||||
<programlisting>
|
||||
postInstall = "ln -sf gzip $out/bin/gunzip; ln -sf gzip $out/bin/zcat";</programlisting>
|
||||
and so a separate build script becomes unnecessary. This should allow us to get rid of most builders in Nixpkgs.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
It is now possible to have the generic builder pass arguments to <command>configure</command> and <command>make</command> that contain whitespace. Previously, for example, you could say in a builder,
|
||||
<programlisting>
|
||||
configureFlags="CFLAGS=-O0"</programlisting>
|
||||
but not
|
||||
<programlisting>
|
||||
configureFlags="CFLAGS=-O0 -g"</programlisting>
|
||||
since the <literal>-g</literal> would be interpreted as a separate argument to <command>configure</command>. Now you can say
|
||||
<programlisting>
|
||||
configureFlagsArray=("CFLAGS=-O0 -g")</programlisting>
|
||||
or similarly
|
||||
<programlisting>
|
||||
configureFlagsArray=("CFLAGS=-O0 -g" "LDFLAGS=-L/foo -L/bar")</programlisting>
|
||||
which does the right thing. Idem for <literal>makeFlags</literal>, <literal>installFlags</literal>, <literal>checkFlags</literal> and <literal>distFlags</literal>.
|
||||
</para>
|
||||
<para>
|
||||
Unfortunately you can't pass arrays to Bash through the environment, so you can't put the array above in a Nix expression, e.g.,
|
||||
<programlisting>
|
||||
configureFlagsArray = ["CFLAGS=-O0 -g"];</programlisting>
|
||||
since it would just be flattened to a since string. However, you <emphasis>can</emphasis> use the inline hooks described above:
|
||||
<programlisting>
|
||||
preConfigure = "configureFlagsArray=(\"CFLAGS=-O0 -g\")";</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The function <function>fetchurl</function> now has support for two different kinds of mirroring of files. First, it has support for <emphasis>content-addressable mirrors</emphasis>. For example, given the <function>fetchurl</function> call
|
||||
<programlisting>
|
||||
fetchurl {
|
||||
url = "http://releases.mozilla.org/<replaceable>...</replaceable>/firefox-2.0.0.6-source.tar.bz2";
|
||||
sha1 = "eb72f55e4a8bf08e8c6ef227c0ade3d068ba1082";
|
||||
}</programlisting>
|
||||
<function>fetchurl</function> will first try to download this file from <link
|
||||
xlink:href="http://tarballs.nixos.org/sha1/eb72f55e4a8bf08e8c6ef227c0ade3d068ba1082"/>. If that file doesn’t exist, it will try the original URL. In general, the “content-addressed” location is <replaceable>mirror</replaceable><literal>/</literal><replaceable>hash-type</replaceable><literal>/</literal><replaceable>hash</replaceable>. There is currently only one content-addressable mirror (<link
|
||||
xlink:href="http://tarballs.nixos.org"/>), but more can be specified in the <varname>hashedMirrors</varname> attribute in <filename>pkgs/build-support/fetchurl/mirrors.nix</filename>, or by setting the <envar>NIX_HASHED_MIRRORS</envar> environment variable to a whitespace-separated list of URLs.
|
||||
</para>
|
||||
<para>
|
||||
Second, <function>fetchurl</function> has support for widely-mirrored distribution sites such as SourceForge or the Linux kernel archives. Given a URL of the form <literal>mirror://<replaceable>site</replaceable>/<replaceable>path</replaceable></literal>, it will try to download <replaceable>path</replaceable> from a configurable list of mirrors for <replaceable>site</replaceable>. (This idea was borrowed from Gentoo Linux.) Example:
|
||||
<programlisting>
|
||||
fetchurl {
|
||||
url = mirror://gnu/gcc/gcc-4.2.0/gcc-core-4.2.0.tar.bz2;
|
||||
sha256 = "0ykhzxhr8857dr97z0j9wyybfz1kjr71xk457cfapfw5fjas4ny1";
|
||||
}</programlisting>
|
||||
Currently <replaceable>site</replaceable> can be <literal>sourceforge</literal>, <literal>gnu</literal> and <literal>kernel</literal>. The list of mirrors is defined in <filename>pkgs/build-support/fetchurl/mirrors.nix</filename>. You can override the list of mirrors for a particular site by setting the environment variable <envar>NIX_MIRRORS_<replaceable>site</replaceable></envar>, e.g.
|
||||
<programlisting>
|
||||
export NIX_MIRRORS_sourceforge=http://osdn.dl.sourceforge.net/sourceforge/</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Important updates:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Glibc 2.5.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
GCC 4.1.2.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Gnome 2.16.3.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
X11R7.2.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Linux 2.6.21.7 and 2.6.22.6.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Emacs 22.1.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Major new packages:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
KDE 3.5.6 Base.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Wine 0.9.43.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
OpenOffice 2.2.1.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Many Linux system packages to support NixOS.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following people contributed to this release: Andres Löh, Arie Middelkoop, Armijn Hemel, Eelco Dolstra, Marc Weber, Mart Kolthof, Martin Bravenboer, Michael Raskin, Wouter den Breejen and Yury G. Kudryashov.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="release-notes-0.10">
|
||||
<title>Release 0.10 (October 12, 2006)</title>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
This release of Nixpkgs requires <link
|
||||
xlink:href='https://nixos.org/releases/nix/nix-0.10/'>Nix 0.10</link> or higher.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
This release has the following improvements:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<filename>pkgs/system/all-packages-generic.nix</filename> is gone, we now just have <filename>pkgs/top-level/all-packages.nix</filename> that contains all available packages. This should cause much less confusion with users. <filename>all-packages.nix</filename> is a function that by default returns packages for the current platform, but you can override this by specifying a different <varname>system</varname> argument.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Certain packages in Nixpkgs are now user-configurable through a configuration file, i.e., without having to edit the Nix expressions in Nixpkgs. For instance, the Firefox provided in the Nixpkgs channel is built without the RealPlayer plugin (for legal reasons). Previously, you could easily enable RealPlayer support by editing the call to the Firefox function in <filename>all-packages.nix</filename>, but such changes are not respected when Firefox is subsequently updated through the Nixpkgs channel.
|
||||
</para>
|
||||
<para>
|
||||
The Nixpkgs configuration file (found in <filename>~/.nixpkgs/config.nix</filename> or through the <envar>NIXPKGS_CONFIG</envar> environment variable) is an attribute set that contains configuration options that <filename>all-packages.nix</filename> reads and uses for certain packages. For instance, the following configuration file:
|
||||
<programlisting>
|
||||
{
|
||||
firefox = {
|
||||
enableRealPlayer = true;
|
||||
};
|
||||
}</programlisting>
|
||||
persistently enables RealPlayer support in the Firefox build.
|
||||
</para>
|
||||
<para>
|
||||
(Actually, <literal>firefox.enableRealPlayer</literal> is the <emphasis>only</emphasis> configuration option currently available, but more are sure to be added.)
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Support for new platforms:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>i686-cygwin</literal>, i.e., Windows (using <link xlink:href="http://www.cygwin.com/">Cygwin</link>). The standard environment on <literal>i686-cygwin</literal> by default builds binaries for the Cygwin environment (i.e., it uses Cygwin tools and produces executables that use the Cygwin library). However, there is also a standard environment that produces binaries that use <link
|
||||
xlink:href="http://www.mingw.org/">MinGW</link>. You can use it by calling <filename>all-package.nix</filename> with the <varname>stdenvType</varname> argument set to <literal>"i686-mingw"</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>i686-darwin</literal>, i.e., Mac OS X on Intel CPUs.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>powerpc-linux</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>x86_64-linux</literal>, i.e., Linux on 64-bit AMD/Intel CPUs. Unlike <literal>i686-linux</literal>, this platform doesn’t have a pure <literal>stdenv</literal> yet.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The default compiler is now GCC 4.1.1.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
X11 updated to X.org’s X11R7.1.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Notable new packages:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Opera.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Microsoft Visual C++ 2005 Express Edition and the Windows SDK.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
In total there are now around 809 packages in Nixpkgs.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
It is now <emphasis>much</emphasis> easier to override the default C compiler and other tools in <literal>stdenv</literal> for specific packages. <filename>all-packages.nix</filename> provides two utility functions for this purpose: <function>overrideGCC</function> and <function>overrideInStdenv</function>. Both take a <literal>stdenv</literal> and return an augmented <literal>stdenv</literal>; the formed changes the C compiler, and the latter adds additional packages to the front of <literal>stdenv</literal>’s initial <envar>PATH</envar>, allowing tools to be overridden.
|
||||
</para>
|
||||
<para>
|
||||
For instance, the package <varname>strategoxt</varname> doesn’t build with the GNU Make in <literal>stdenv</literal> (version 3.81), so we call it with an augmented <literal>stdenv</literal> that uses GNU Make 3.80:
|
||||
<programlisting>
|
||||
strategoxt = (import ../development/compilers/strategoxt) {
|
||||
inherit fetchurl pkgconfig sdf aterm;
|
||||
stdenv = overrideInStdenv stdenv [gnumake380];
|
||||
};
|
||||
|
||||
gnumake380 = <replaceable>...</replaceable>;</programlisting>
|
||||
Likewise, there are many packages that don’t compile with the default GCC (4.1.1), but that’s easily fixed:
|
||||
<programlisting>
|
||||
exult = import ../games/exult {
|
||||
inherit fetchurl SDL SDL_mixer zlib libpng unzip;
|
||||
stdenv = overrideGCC stdenv gcc34;
|
||||
};</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
It has also become much easier to experiment with changes to the <literal>stdenv</literal> setup script (which notably contains the generic builder). Since edits to <filename>pkgs/stdenv/generic/setup.sh</filename> trigger a rebuild of <emphasis>everything</emphasis>, this was formerly quite painful. But now <literal>stdenv</literal> contains a function to “regenerate” <literal>stdenv</literal> with a different setup script, allowing the use of a different setup script for specific packages:
|
||||
<programlisting>
|
||||
pkg = import <replaceable>...</replaceable> {
|
||||
stdenv = stdenv.regenerate ./my-setup.sh;
|
||||
<replaceable>...</replaceable>
|
||||
}</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Packages can now have a human-readable <emphasis>description</emphasis> field. Package descriptions are shown by <literal>nix-env -qa --description</literal>. In addition, they’re shown on the Nixpkgs release page. A description can be added to a package as follows:
|
||||
<programlisting>
|
||||
stdenv.mkDerivation {
|
||||
name = "exult-1.2";
|
||||
<replaceable>...</replaceable>
|
||||
meta = {
|
||||
description = "A reimplementation of the Ultima VII game engine";
|
||||
};
|
||||
}</programlisting>
|
||||
The <varname>meta</varname> attribute is not passed to the builder, so changes to the description do not trigger a rebuild. Additional <varname>meta</varname> attributes may be defined in the future (such as the URL of the package’s homepage, the license, etc.).
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
The following people contributed to this release: Andres Löh, Armijn Hemel, Christof Douma, Eelco Dolstra, Eelco Visser, Mart Kolthof, Martin Bravenboer, Merijn de Jonge, Rob Vermaas and Roy van den Broek.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="release-notes-0.9">
|
||||
<title>Release 0.9 (January 31, 2006)</title>
|
||||
|
||||
<para>
|
||||
There have been zillions of changes since the last release of Nixpkgs. Many packages have been added or updated. The following are some of the more notable changes:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Distribution files have been moved to <link
|
||||
xlink:href="https://nixos.org/" />.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The C library on Linux, Glibc, has been updated to version 2.3.6.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The default compiler is now GCC 3.4.5. GCC 4.0.2 is also available.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The old, unofficial Xlibs has been replaced by the official modularised X11 distribution from X.org, i.e., X11R7.0. X11R7.0 consists of 287 (!) packages, all of which are in Nixpkgs though not all have been tested. It is now possible to build a working X server (previously we only had X client libraries). We use a fully Nixified X server on NixOS.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The Sun JDK 5 has been purified, i.e., it doesn’t require any non-Nix components such as <filename>/lib/ld-linux.so.2</filename>. This means that Java applications such as Eclipse and Azureus can run on NixOS.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Hardware-accelerated OpenGL support, used by games like Quake 3 (which is now built from source).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Improved support for FreeBSD on x86.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Improved Haskell support; e.g., the GHC build is now pure.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Some support for cross-compilation: cross-compiling builds of GCC and Binutils, and cross-compiled builds of the C library uClibc.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Notable new packages:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
teTeX, including support for building LaTeX documents using Nix (with automatic dependency determination).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ruby.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
System-level packages to support NixOS, e.g. Grub, GNU <literal>parted</literal> and so on.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>ecj</literal>, the Eclipse Compiler for Java, so we finally have a freely distributable compiler that supports Java 5.0.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>php</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The GIMP.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Inkscape.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
GAIM.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>kdelibs</literal>. This allows us to add KDE-based packages (such as <literal>kcachegrind</literal>).
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
The following people contributed to this release: Andres Löh, Armijn Hemel, Bogdan Dumitriu, Christof Douma, Eelco Dolstra, Eelco Visser, Mart Kolthof, Martin Bravenboer, Rob Vermaas and Roy van den Broek.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="release-notes-0.8">
|
||||
<title>Release 0.8 (April 11, 2005)</title>
|
||||
|
||||
<para>
|
||||
This release is mostly to remain synchronised with the changed hashing scheme in Nix 0.8.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Notable updates:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Adobe Reader 7.0
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Various security updates (zlib 1.2.2, etc.)
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="release-notes-0.7">
|
||||
<title>Release 0.7 (March 14, 2005)</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
The bootstrap process for the standard build environment on Linux (stdenv-linux) has been improved. It is no longer dependent in its initial bootstrap stages on the system Glibc, GCC, and other tools. Rather, Nixpkgs contains a statically linked bash and curl, and uses that to download other statically linked tools. These are then used to build a Glibc and dynamically linked versions of all other tools.
|
||||
</para>
|
||||
<para>
|
||||
This change also makes the bootstrap process faster. For instance, GCC is built only once instead of three times.
|
||||
</para>
|
||||
<para>
|
||||
(Contributed by Armijn Hemel.)
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Tarballs used by Nixpkgs are now obtained from the same server that hosts Nixpkgs (<link
|
||||
xlink:href="http://catamaran.labs.cs.uu.nl/" />). This reduces the risk of packages being unbuildable due to moved or deleted files on various servers.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
There now is a generic mechanism for building Perl modules. See the various Perl modules defined in pkgs/system/all-packages-generic.nix.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Notable new packages:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Qt 3
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
MySQL
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
MythTV
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Mono
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
MonoDevelop (alpha)
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Xine
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Notable updates:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
GCC 3.4.3
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Glibc 2.3.4
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
GTK 2.6
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</article>
|
||||
@ -153,6 +153,24 @@ Add the following to your `mkDerivation` invocation.
|
||||
doCheck = stdenv.hostPlatform == stdenv.buildPlatform;
|
||||
```
|
||||
|
||||
#### Package using Meson needs to run binaries for the host platform during build. {#cross-meson-runs-host-code}
|
||||
|
||||
Add `mesonEmulatorHook` cross conditionally to `nativeBuildInputs`.
|
||||
|
||||
e.g.
|
||||
|
||||
```
|
||||
nativeBuildInputs = [
|
||||
meson
|
||||
] ++ lib.optionals (stdenv.buildPlatform != stdenv.hostPlatform) [
|
||||
mesonEmulatorHook
|
||||
];
|
||||
```
|
||||
|
||||
Example of an error which this fixes.
|
||||
|
||||
`[Errno 8] Exec format error: './gdk3-scan'`
|
||||
|
||||
## Cross-building packages {#sec-cross-usage}
|
||||
|
||||
Nixpkgs can be instantiated with `localSystem` alone, in which case there is no cross-compiling and everything is built by and for that system, or also with `crossSystem`, in which case packages run on the latter, but all building happens on the former. Both parameters take the same schema as the 3 (build, host, and target) platforms defined in the previous section. As mentioned above, `lib.systems.examples` has some platforms which are used as arguments for these parameters in practice. You can use them programmatically, or on the command line:
|
||||
|
||||
@ -175,6 +175,40 @@ The NixOS tests are available as `nixosTests` in parameters of derivations. For
|
||||
|
||||
NixOS tests run in a VM, so they are slower than regular package tests. For more information see [NixOS module tests](https://nixos.org/manual/nixos/stable/#sec-nixos-tests).
|
||||
|
||||
Alternatively, you can specify other derivations as tests. You can make use of
|
||||
the optional parameter to inject the correct package without
|
||||
relying on non-local definitions, even in the presence of `overrideAttrs`.
|
||||
Here that's `finalAttrs.finalPackage`, but you could choose a different name if
|
||||
`finalAttrs` already exists in your scope.
|
||||
|
||||
`(mypkg.overrideAttrs f).passthru.tests` will be as expected, as long as the
|
||||
definition of `tests` does not rely on the original `mypkg` or overrides it in
|
||||
all places.
|
||||
|
||||
```nix
|
||||
# my-package/default.nix
|
||||
{ stdenv, callPackage }:
|
||||
stdenv.mkDerivation (finalAttrs: {
|
||||
# ...
|
||||
passthru.tests.example = callPackage ./example.nix { my-package = finalAttrs.finalPackage; };
|
||||
})
|
||||
```
|
||||
|
||||
```nix
|
||||
# my-package/example.nix
|
||||
{ runCommand, lib, my-package, ... }:
|
||||
runCommand "my-package-test" {
|
||||
nativeBuildInputs = [ my-package ];
|
||||
src = lib.sources.sourcesByRegex ./. [ ".*.in" ".*.expected" ];
|
||||
} ''
|
||||
my-package --help
|
||||
my-package <example.in >example.actual
|
||||
diff -U3 --color=auto example.expected example.actual
|
||||
mkdir $out
|
||||
''
|
||||
```
|
||||
|
||||
|
||||
### `timeout` {#var-meta-timeout}
|
||||
|
||||
A timeout (in seconds) for building the derivation. If the derivation takes longer than this time to build, it can fail due to breaking the timeout. However, all computers do not have the same computing power, hence some builders may decide to apply a multiplicative factor to this value. When filling this value in, try to keep it approximately consistent with other values already present in `nixpkgs`.
|
||||
@ -215,3 +249,31 @@ Unfree package that cannot be redistributed. You can build it yourself, but you
|
||||
### `lib.licenses.unfreeRedistributableFirmware`, `"unfree-redistributable-firmware"` {#lib.licenses.unfreeredistributablefirmware-unfree-redistributable-firmware}
|
||||
|
||||
This package supplies unfree, redistributable firmware. This is a separate value from `unfree-redistributable` because not everybody cares whether firmware is free.
|
||||
|
||||
## Source provenance {#sec-meta-sourceProvenance}
|
||||
|
||||
The value of a package's `meta.sourceProvenance` attribute specifies the provenance of the package's derivation outputs.
|
||||
|
||||
If a package contains elements that are not built from the original source by a nixpkgs derivation, the `meta.sourceProvenance` attribute should be a list containing one or more value from `lib.sourceTypes` defined in [`nixpkgs/lib/source-types.nix`](https://github.com/NixOS/nixpkgs/blob/master/lib/source-types.nix).
|
||||
|
||||
Adding this information helps users who have needs related to build transparency and supply-chain security to gain some visibility into their installed software or set policy to allow or disallow installation based on source provenance.
|
||||
|
||||
The presence of a particular `sourceType` in a package's `meta.sourceProvenance` list indicates that the package contains some components falling into that category, though the *absence* of that `sourceType` does not *guarantee* the absence of that category of `sourceType` in the package's contents. A package with no `meta.sourceProvenance` set implies it has no *known* `sourceType`s other than `fromSource`.
|
||||
|
||||
The meaning of the `meta.sourceProvenance` attribute does not depend on the value of the `meta.license` attribute.
|
||||
|
||||
### `lib.sourceTypes.fromSource` {#lib.sourceTypes.fromSource}
|
||||
|
||||
Package elements which are produced by a nixpkgs derivation which builds them from source code.
|
||||
|
||||
### `lib.sourceTypes.binaryNativeCode` {#lib.sourceTypes.binaryNativeCode}
|
||||
|
||||
Native code to be executed on the target system's CPU, built by a third party. This includes packages which wrap a downloaded AppImage or Debian package.
|
||||
|
||||
### `lib.sourceTypes.binaryFirmware` {#lib.sourceTypes.binaryFirmware}
|
||||
|
||||
Code to be executed on a peripheral device or embedded controller, built by a third party.
|
||||
|
||||
### `lib.sourceTypes.binaryBytecode` {#lib.sourceTypes.binaryBytecode}
|
||||
|
||||
Code to run on a VM interpreter or JIT compiled into bytecode by a third party. This includes packages which download Java `.jar` files from another source.
|
||||
|
||||
@ -77,7 +77,7 @@ There is a special handling of the `debug` output, described at [](#stdenv-separ
|
||||
|
||||
A commonly adopted convention in `nixpkgs` is that executables provided by the package are contained within its first output. This convention allows the dependent packages to reference the executables provided by packages in a uniform manner. For instance, provided with the knowledge that the `perl` package contains a `perl` executable it can be referenced as `${pkgs.perl}/bin/perl` within a Nix derivation that needs to execute a Perl script.
|
||||
|
||||
The `glibc` package is a deliberate single exception to the “binaries first” convention. The `glibc` has `libs` as its first output allowing the libraries provided by `glibc` to be referenced directly (e.g. `${stdenv.glibc}/lib/ld-linux-x86-64.so.2`). The executables provided by `glibc` can be accessed via its `bin` attribute (e.g. `${stdenv.glibc.bin}/bin/ldd`).
|
||||
The `glibc` package is a deliberate single exception to the “binaries first” convention. The `glibc` has `libs` as its first output allowing the libraries provided by `glibc` to be referenced directly (e.g. `${glibc}/lib/ld-linux-x86-64.so.2`). The executables provided by `glibc` can be accessed via its `bin` attribute (e.g. `${lib.getBin stdenv.cc.libc}/bin/ldd`).
|
||||
|
||||
The reason for why `glibc` deviates from the convention is because referencing a library provided by `glibc` is a very common operation among Nix packages. For instance, third-party executables packaged by Nix are typically patched and relinked with the relevant version of `glibc` libraries from Nix packages (please see the documentation on [patchelf](https://github.com/NixOS/patchelf) for more details).
|
||||
|
||||
|
||||
@ -317,6 +317,60 @@ The script will be usually run from the root of the Nixpkgs repository but you s
|
||||
|
||||
For information about how to run the updates, execute `nix-shell maintainers/scripts/update.nix`.
|
||||
|
||||
### Recursive attributes in `mkDerivation`
|
||||
|
||||
If you pass a function to `mkDerivation`, it will receive as its argument the final arguments, including the overrides when reinvoked via `overrideAttrs`. For example:
|
||||
|
||||
```nix
|
||||
mkDerivation (finalAttrs: {
|
||||
pname = "hello";
|
||||
withFeature = true;
|
||||
configureFlags =
|
||||
lib.optionals finalAttrs.withFeature ["--with-feature"];
|
||||
})
|
||||
```
|
||||
|
||||
Note that this does not use the `rec` keyword to reuse `withFeature` in `configureFlags`.
|
||||
The `rec` keyword works at the syntax level and is unaware of overriding.
|
||||
|
||||
Instead, the definition references `finalAttrs`, allowing users to change `withFeature`
|
||||
consistently with `overrideAttrs`.
|
||||
|
||||
`finalAttrs` also contains the attribute `finalPackage`, which includes the output paths, etc.
|
||||
|
||||
Let's look at a more elaborate example to understand the differences between
|
||||
various bindings:
|
||||
|
||||
```nix
|
||||
# `pkg` is the _original_ definition (for illustration purposes)
|
||||
let pkg =
|
||||
mkDerivation (finalAttrs: {
|
||||
# ...
|
||||
|
||||
# An example attribute
|
||||
packages = [];
|
||||
|
||||
# `passthru.tests` is a commonly defined attribute.
|
||||
passthru.tests.simple = f finalAttrs.finalPackage;
|
||||
|
||||
# An example of an attribute containing a function
|
||||
passthru.appendPackages = packages':
|
||||
finalAttrs.finalPackage.overrideAttrs (newSelf: super: {
|
||||
packages = super.packages ++ packages';
|
||||
});
|
||||
|
||||
# For illustration purposes; referenced as
|
||||
# `(pkg.overrideAttrs(x)).finalAttrs` etc in the text below.
|
||||
passthru.finalAttrs = finalAttrs;
|
||||
passthru.original = pkg;
|
||||
});
|
||||
in pkg
|
||||
```
|
||||
|
||||
Unlike the `pkg` binding in the above example, the `finalAttrs` parameter always references the final attributes. For instance `(pkg.overrideAttrs(x)).finalAttrs.finalPackage` is identical to `pkg.overrideAttrs(x)`, whereas `(pkg.overrideAttrs(x)).original` is the same as the original `pkg`.
|
||||
|
||||
See also the section about [`passthru.tests`](#var-meta-tests).
|
||||
|
||||
## Phases {#sec-stdenv-phases}
|
||||
|
||||
`stdenv.mkDerivation` sets the Nix [derivation](https://nixos.org/manual/nix/stable/expressions/derivations.html#derivations)'s builder to a script that loads the stdenv `setup.sh` bash library and calls `genericBuild`. Most packaging functions rely on this default builder.
|
||||
@ -815,7 +869,7 @@ makeWrapper $out/bin/foo $wrapperfile --set FOOBAR baz
|
||||
makeWrapper $out/bin/foo $wrapperfile --prefix PATH : ${lib.makeBinPath [ hello git ]}
|
||||
```
|
||||
|
||||
There’s many more kinds of arguments, they are documented in `nixpkgs/pkgs/build-support/setup-hooks/make-wrapper.sh` for the `makeWrapper` implementation and in `nixpkgs/pkgs/build-support/setup-hooks/make-binary-wrapper.sh` for the `makeBinaryWrapper` implementation.
|
||||
There’s many more kinds of arguments, they are documented in `nixpkgs/pkgs/build-support/setup-hooks/make-wrapper.sh` for the `makeWrapper` implementation and in `nixpkgs/pkgs/build-support/setup-hooks/make-binary-wrapper/make-binary-wrapper.sh` for the `makeBinaryWrapper` implementation.
|
||||
|
||||
`wrapProgram` is a convenience function you probably want to use most of the time, implemented by both `makeWrapper` and `makeBinaryWrapper`.
|
||||
|
||||
|
||||
@ -176,6 +176,15 @@ You can define a function called `packageOverrides` in your local `~/.config/nix
|
||||
}
|
||||
```
|
||||
|
||||
## `config` Options Reference {#sec-config-options-reference}
|
||||
|
||||
The following attributes can be passed in [`config`](#chap-packageconfig).
|
||||
|
||||
```{=docbook}
|
||||
<include xmlns="http://www.w3.org/2001/XInclude" href="../doc-support/result/config-options.docbook.xml"/>
|
||||
```
|
||||
|
||||
|
||||
## Declarative Package Management {#sec-declarative-package-management}
|
||||
|
||||
### Build an environment {#sec-building-environment}
|
||||
|
||||
@ -39,14 +39,18 @@ The function `overrideAttrs` allows overriding the attribute set passed to a `st
|
||||
Example usage:
|
||||
|
||||
```nix
|
||||
helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
|
||||
helloWithDebug = pkgs.hello.overrideAttrs (finalAttrs: previousAttrs: {
|
||||
separateDebugInfo = true;
|
||||
});
|
||||
```
|
||||
|
||||
In the above example, the `separateDebugInfo` attribute is overridden to be true, thus building debug info for `helloWithDebug`, while all other attributes will be retained from the original `hello` package.
|
||||
|
||||
The argument `oldAttrs` is conventionally used to refer to the attr set originally passed to `stdenv.mkDerivation`.
|
||||
The argument `previousAttrs` is conventionally used to refer to the attr set originally passed to `stdenv.mkDerivation`.
|
||||
|
||||
The argument `finalAttrs` refers to the final attributes passed to `mkDerivation`, plus the `finalPackage` attribute which is equal to the result of `mkDerivation` or subsequent `overrideAttrs` calls.
|
||||
|
||||
If only a one-argument function is written, the argument has the meaning of `previousAttrs`.
|
||||
|
||||
::: {.note}
|
||||
Note that `separateDebugInfo` is processed only by the `stdenv.mkDerivation` function, not the generated, raw Nix derivation. Thus, using `overrideDerivation` will not work in this case, as it overrides only the attributes of the final derivation. It is for this reason that `overrideAttrs` should be preferred in (almost) all cases to `overrideDerivation`, i.e. to allow using `stdenv.mkDerivation` to process input arguments, as well as the fact that it is easier to use (you can use the same attribute names you see in your Nix code, instead of the ones generated (e.g. `buildInputs` vs `nativeBuildInputs`), and it involves less typing).
|
||||
|
||||
@ -11,9 +11,7 @@
|
||||
|
||||
lib = import ./lib;
|
||||
|
||||
systems = lib.systems.supported.hydra;
|
||||
|
||||
forAllSystems = f: lib.genAttrs systems (system: f system);
|
||||
forAllSystems = f: lib.genAttrs lib.systems.flakeExposed (system: f system);
|
||||
|
||||
in
|
||||
{
|
||||
|
||||
@ -248,7 +248,7 @@ rec {
|
||||
/* Apply fold functions to values grouped by key.
|
||||
|
||||
Example:
|
||||
foldAttrs (n: a: [n] ++ a) [] [{ a = 2; } { a = 3; }]
|
||||
foldAttrs (item: acc: [item] ++ acc) [] [{ a = 2; } { a = 3; }]
|
||||
=> { a = [ 2 3 ]; }
|
||||
*/
|
||||
foldAttrs = op: nul:
|
||||
|
||||
@ -36,6 +36,7 @@ let
|
||||
|
||||
# constants
|
||||
licenses = callLibs ./licenses.nix;
|
||||
sourceTypes = callLibs ./source-types.nix;
|
||||
systems = callLibs ./systems;
|
||||
|
||||
# serialization
|
||||
@ -70,7 +71,7 @@ let
|
||||
info showWarnings nixpkgsVersion version isInOldestRelease
|
||||
mod compare splitByAndCompare
|
||||
functionArgs setFunctionArgs isFunction toFunction
|
||||
toHexString toBaseDigits;
|
||||
toHexString toBaseDigits inPureEvalMode;
|
||||
inherit (self.fixedPoints) fix fix' converge extends composeExtensions
|
||||
composeManyExtensions makeExtensible makeExtensibleWithCustomName;
|
||||
inherit (self.attrsets) attrByPath hasAttrByPath setAttrByPath
|
||||
@ -94,7 +95,8 @@ let
|
||||
concatImapStringsSep makeSearchPath makeSearchPathOutput
|
||||
makeLibraryPath makeBinPath optionalString
|
||||
hasInfix hasPrefix hasSuffix stringToCharacters stringAsChars escape
|
||||
escapeShellArg escapeShellArgs escapeRegex escapeXML replaceChars lowerChars
|
||||
escapeShellArg escapeShellArgs isValidPosixName toShellVar toShellVars
|
||||
escapeRegex escapeXML replaceChars lowerChars
|
||||
upperChars toLower toUpper addContextFrom splitString
|
||||
removePrefix removeSuffix versionOlder versionAtLeast
|
||||
getName getVersion
|
||||
@ -108,7 +110,7 @@ let
|
||||
makeScope makeScopeWithSplicing;
|
||||
inherit (self.meta) addMetaAttrs dontDistribute setName updateName
|
||||
appendToName mapDerivationAttrset setPrio lowPrio lowPrioSet hiPrio
|
||||
hiPrioSet getLicenseFromSpdxId;
|
||||
hiPrioSet getLicenseFromSpdxId getExe;
|
||||
inherit (self.sources) pathType pathIsDirectory cleanSourceFilter
|
||||
cleanSource sourceByRegex sourceFilesBySuffices
|
||||
commitIdFromGitRepo cleanSourceWith pathHasContext
|
||||
@ -129,7 +131,9 @@ let
|
||||
getValues getFiles
|
||||
optionAttrSetToDocList optionAttrSetToDocList'
|
||||
scrubOptionValue literalExpression literalExample literalDocBook
|
||||
showOption showFiles unknownModule mkOption mkPackageOption;
|
||||
showOption showOptionWithDefLocs showFiles
|
||||
unknownModule mkOption mkPackageOption
|
||||
mdDoc literalMD;
|
||||
inherit (self.types) isType setType defaultTypeMerge defaultFunctor
|
||||
isOptionType mkOptionType;
|
||||
inherit (self.asserts)
|
||||
|
||||
@ -251,6 +251,16 @@ rec {
|
||||
}:
|
||||
assert builtins.isInt depthLimit;
|
||||
let
|
||||
specialAttrs = [
|
||||
"__functor"
|
||||
"__functionArgs"
|
||||
"__toString"
|
||||
"__pretty"
|
||||
];
|
||||
stepIntoAttr = evalNext: name:
|
||||
if builtins.elem name specialAttrs
|
||||
then id
|
||||
else evalNext;
|
||||
transform = depth:
|
||||
if depthLimit != null && depth > depthLimit then
|
||||
if throwOnDepthLimit
|
||||
@ -261,7 +271,7 @@ rec {
|
||||
let
|
||||
evalNext = x: mapAny (depth + 1) (transform (depth + 1) x);
|
||||
in
|
||||
if isAttrs v then mapAttrs (const evalNext) v
|
||||
if isAttrs v then mapAttrs (stepIntoAttr evalNext) v
|
||||
else if isList v then map evalNext v
|
||||
else transform (depth + 1) v;
|
||||
in
|
||||
|
||||
@ -285,6 +285,11 @@ in mkLicense lset) ({
|
||||
fullName = "DOC License";
|
||||
};
|
||||
|
||||
drl10 = {
|
||||
spdxId = "DRL-1.0";
|
||||
fullName = "Detection Rule License 1.0";
|
||||
};
|
||||
|
||||
eapl = {
|
||||
fullName = "EPSON AVASYS PUBLIC LICENSE";
|
||||
url = "https://avasys.jp/hp/menu000000700/hpg000000603.htm";
|
||||
|
||||
@ -507,7 +507,7 @@ rec {
|
||||
compareLists compare [ "a" ] []
|
||||
=> 1
|
||||
compareLists compare [ "a" "b" ] [ "a" "c" ]
|
||||
=> 1
|
||||
=> -1
|
||||
*/
|
||||
compareLists = cmp: a: b:
|
||||
if a == []
|
||||
|
||||
14
lib/meta.nix
14
lib/meta.nix
@ -126,4 +126,18 @@ rec {
|
||||
lib.warn "getLicenseFromSpdxId: No license matches the given SPDX ID: ${licstr}"
|
||||
{ shortName = licstr; }
|
||||
);
|
||||
|
||||
/* Get the path to the main program of a derivation with either
|
||||
meta.mainProgram or pname or name
|
||||
|
||||
Type: getExe :: derivation -> string
|
||||
|
||||
Example:
|
||||
getExe pkgs.hello
|
||||
=> "/nix/store/g124820p9hlv4lj8qplzxw1c44dxaw1k-hello-2.12/bin/hello"
|
||||
getExe pkgs.mustache-go
|
||||
=> "/nix/store/am9ml4f4ywvivxnkiaqwr0hyxka1xjsf-mustache-go-1.3.0/bin/mustache"
|
||||
*/
|
||||
getExe = x:
|
||||
"${lib.getBin x}/bin/${x.meta.mainProgram or (lib.getName x)}";
|
||||
}
|
||||
|
||||
@ -156,7 +156,10 @@ rec {
|
||||
type = types.lazyAttrsOf types.raw;
|
||||
# Only render documentation once at the root of the option tree,
|
||||
# not for all individual submodules.
|
||||
internal = prefix != [];
|
||||
# Allow merging option decls to make this internal regardless.
|
||||
${if prefix == []
|
||||
then null # unset => visible
|
||||
else "internal"} = true;
|
||||
# TODO: Change the type of this option to a submodule with a
|
||||
# freeformType, so that individual arguments can be documented
|
||||
# separately
|
||||
@ -342,7 +345,7 @@ rec {
|
||||
evalModules (evalModulesArgs // {
|
||||
modules = regularModules ++ modules;
|
||||
specialArgs = evalModulesArgs.specialArgs or {} // specialArgs;
|
||||
prefix = extendArgs.prefix or evalModulesArgs.prefix;
|
||||
prefix = extendArgs.prefix or evalModulesArgs.prefix or [];
|
||||
});
|
||||
|
||||
type = lib.types.submoduleWith {
|
||||
@ -459,6 +462,7 @@ rec {
|
||||
config = addFreeformType (addMeta (m.config or {}));
|
||||
}
|
||||
else
|
||||
lib.throwIfNot (isAttrs m) "module ${file} (${key}) does not look like a module."
|
||||
{ _file = toString m._file or file;
|
||||
key = toString m.key or key;
|
||||
disabledModules = m.disabledModules or [];
|
||||
|
||||
@ -7,6 +7,7 @@ let
|
||||
collect
|
||||
concatLists
|
||||
concatMap
|
||||
concatMapStringsSep
|
||||
elemAt
|
||||
filter
|
||||
foldl'
|
||||
@ -120,7 +121,7 @@ rec {
|
||||
Example:
|
||||
mkPackageOption pkgs "GHC" {
|
||||
default = [ "ghc" ];
|
||||
example = "pkgs.haskell.package.ghc922.ghc.withPackages (hkgs: [ hkgs.primes ])";
|
||||
example = "pkgs.haskell.package.ghc923.ghc.withPackages (hkgs: [ hkgs.primes ])";
|
||||
}
|
||||
=> { _type = "option"; default = «derivation /nix/store/jxx55cxsjrf8kyh3fp2ya17q99w7541r-ghc-8.10.7.drv»; defaultText = { ... }; description = "The GHC package to use."; example = { ... }; type = { ... }; }
|
||||
*/
|
||||
@ -241,6 +242,8 @@ rec {
|
||||
in if ss != {} then optionAttrSetToDocList' opt.loc ss else [];
|
||||
subOptionsVisible = docOption.visible && opt.visible or null != "shallow";
|
||||
in
|
||||
# To find infinite recursion in NixOS option docs:
|
||||
# builtins.trace opt.loc
|
||||
[ docOption ] ++ optionals subOptionsVisible subOptions) (collect isOption options);
|
||||
|
||||
|
||||
@ -280,6 +283,21 @@ rec {
|
||||
if ! isString text then throw "literalDocBook expects a string."
|
||||
else { _type = "literalDocBook"; inherit text; };
|
||||
|
||||
/* Transition marker for documentation that's already migrated to markdown
|
||||
syntax.
|
||||
*/
|
||||
mdDoc = text:
|
||||
if ! isString text then throw "mdDoc expects a string."
|
||||
else { _type = "mdDoc"; inherit text; };
|
||||
|
||||
/* For use in the `defaultText` and `example` option attributes. Causes the
|
||||
given MD text to be inserted verbatim in the documentation, for when
|
||||
a `literalExpression` would be too hard to read.
|
||||
*/
|
||||
literalMD = text:
|
||||
if ! isString text then throw "literalMD expects a string."
|
||||
else { _type = "literalMD"; inherit text; };
|
||||
|
||||
# Helper functions.
|
||||
|
||||
/* Convert an option, described as a list of the option parts in to a
|
||||
@ -325,6 +343,11 @@ rec {
|
||||
in "\n- In `${def.file}'${result}"
|
||||
) defs;
|
||||
|
||||
showOptionWithDefLocs = opt: ''
|
||||
${showOption opt.loc}, with values defined in:
|
||||
${concatMapStringsSep "\n" (defFile: " - ${defFile}") opt.files}
|
||||
'';
|
||||
|
||||
unknownModule = "<unknown-file>";
|
||||
|
||||
}
|
||||
|
||||
19
lib/source-types.nix
Normal file
19
lib/source-types.nix
Normal file
@ -0,0 +1,19 @@
|
||||
{ lib }:
|
||||
|
||||
let
|
||||
defaultSourceType = tname: {
|
||||
shortName = tname;
|
||||
isSource = false;
|
||||
};
|
||||
in lib.mapAttrs (tname: tset: defaultSourceType tname // tset) {
|
||||
|
||||
fromSource = {
|
||||
isSource = true;
|
||||
};
|
||||
|
||||
binaryNativeCode = {};
|
||||
|
||||
binaryBytecode = {};
|
||||
|
||||
binaryFirmware = {};
|
||||
}
|
||||
@ -17,6 +17,7 @@ rec {
|
||||
head
|
||||
isInt
|
||||
isList
|
||||
isAttrs
|
||||
isString
|
||||
match
|
||||
parseDrvName
|
||||
@ -253,7 +254,7 @@ rec {
|
||||
=> false
|
||||
*/
|
||||
hasInfix = infix: content:
|
||||
builtins.match ".*${escapeRegex infix}.*" content != null;
|
||||
builtins.match ".*${escapeRegex infix}.*" "${content}" != null;
|
||||
|
||||
/* Convert a string to a list of characters (i.e. singleton strings).
|
||||
This allows you to, e.g., map a function over each character. However,
|
||||
@ -324,6 +325,66 @@ rec {
|
||||
*/
|
||||
escapeShellArgs = concatMapStringsSep " " escapeShellArg;
|
||||
|
||||
/* Test whether the given name is a valid POSIX shell variable name.
|
||||
|
||||
Type: string -> bool
|
||||
|
||||
Example:
|
||||
isValidPosixName "foo_bar000"
|
||||
=> true
|
||||
isValidPosixName "0-bad.jpg"
|
||||
=> false
|
||||
*/
|
||||
isValidPosixName = name: match "[a-zA-Z_][a-zA-Z0-9_]*" name != null;
|
||||
|
||||
/* Translate a Nix value into a shell variable declaration, with proper escaping.
|
||||
|
||||
The value can be a string (mapped to a regular variable), a list of strings
|
||||
(mapped to a Bash-style array) or an attribute set of strings (mapped to a
|
||||
Bash-style associative array). Note that "string" includes string-coercible
|
||||
values like paths or derivations.
|
||||
|
||||
Strings are translated into POSIX sh-compatible code; lists and attribute sets
|
||||
assume a shell that understands Bash syntax (e.g. Bash or ZSH).
|
||||
|
||||
Type: string -> (string | listOf string | attrsOf string) -> string
|
||||
|
||||
Example:
|
||||
''
|
||||
${toShellVar "foo" "some string"}
|
||||
[[ "$foo" == "some string" ]]
|
||||
''
|
||||
*/
|
||||
toShellVar = name: value:
|
||||
lib.throwIfNot (isValidPosixName name) "toShellVar: ${name} is not a valid shell variable name" (
|
||||
if isAttrs value && ! isCoercibleToString value then
|
||||
"declare -A ${name}=(${
|
||||
concatStringsSep " " (lib.mapAttrsToList (n: v:
|
||||
"[${escapeShellArg n}]=${escapeShellArg v}"
|
||||
) value)
|
||||
})"
|
||||
else if isList value then
|
||||
"declare -a ${name}=(${escapeShellArgs value})"
|
||||
else
|
||||
"${name}=${escapeShellArg value}"
|
||||
);
|
||||
|
||||
/* Translate an attribute set into corresponding shell variable declarations
|
||||
using `toShellVar`.
|
||||
|
||||
Type: attrsOf (string | listOf string | attrsOf string) -> string
|
||||
|
||||
Example:
|
||||
let
|
||||
foo = "value";
|
||||
bar = foo;
|
||||
in ''
|
||||
${toShellVars { inherit foo bar; }}
|
||||
[[ "$foo" == "$bar" ]]
|
||||
''
|
||||
*/
|
||||
toShellVars = vars: concatStringsSep "\n" (lib.mapAttrsToList toShellVar vars);
|
||||
|
||||
/* Turn a string into a Nix expression representing that string
|
||||
|
||||
Type: string -> string
|
||||
|
||||
@ -8,7 +8,16 @@ rec {
|
||||
platforms = import ./platforms.nix { inherit lib; };
|
||||
examples = import ./examples.nix { inherit lib; };
|
||||
architectures = import ./architectures.nix { inherit lib; };
|
||||
supported = import ./supported.nix { inherit lib; };
|
||||
|
||||
/* List of all Nix system doubles the nixpkgs flake will expose the package set
|
||||
for. All systems listed here must be supported by nixpkgs as `localSystem`.
|
||||
|
||||
**Warning**: This attribute is considered experimental and is subject to change.
|
||||
*/
|
||||
flakeExposed = import ./flake-systems.nix { };
|
||||
|
||||
# TODO(@sternenseemann): remove before 21.11
|
||||
supported = throw "2022-05-23: Use lib.systems.flakeExposed instead of lib.systems.supported.hydra, as lib.systems.supported has been removed";
|
||||
|
||||
# Elaborate a `localSystem` or `crossSystem` so that it contains everything
|
||||
# necessary.
|
||||
@ -25,8 +34,11 @@ rec {
|
||||
# Either of these can be losslessly-extracted from `parsed` iff parsing succeeds.
|
||||
system = parse.doubleFromSystem final.parsed;
|
||||
config = parse.tripleFromSystem final.parsed;
|
||||
# Determine whether we are compatible with the provided CPU
|
||||
isCompatible = platform: parse.isCompatible final.parsed.cpu platform.parsed.cpu;
|
||||
# Determine whether we can execute binaries built for the provided platform.
|
||||
canExecute = platform:
|
||||
parse.isCompatible final.parsed.cpu platform.parsed.cpu
|
||||
&& final.parsed.kernel == platform.parsed.kernel;
|
||||
isCompatible = _: throw "2022-05-23: isCompatible has been removed in favor of canExecute, refer to the 22.11 changelog for details";
|
||||
# Derived meta-data
|
||||
libc =
|
||||
/**/ if final.isDarwin then "libSystem"
|
||||
@ -159,7 +171,7 @@ rec {
|
||||
wine = (pkgs.winePackagesFor wine-name).minimal;
|
||||
in
|
||||
if final.parsed.kernel.name == pkgs.stdenv.hostPlatform.parsed.kernel.name &&
|
||||
pkgs.stdenv.hostPlatform.isCompatible final
|
||||
pkgs.stdenv.hostPlatform.canExecute final
|
||||
then "${pkgs.runtimeShell} -c '\"$@\"' --"
|
||||
else if final.isWindows
|
||||
then "${wine}/bin/${wine-name}"
|
||||
|
||||
@ -41,7 +41,7 @@ let
|
||||
# none
|
||||
"aarch64_be-none" "aarch64-none" "arm-none" "armv6l-none" "avr-none" "i686-none"
|
||||
"msp430-none" "or1k-none" "m68k-none" "powerpc-none" "powerpcle-none"
|
||||
"riscv32-none" "riscv64-none" "s390-none" "s390x-none" "vc4-none"
|
||||
"riscv32-none" "riscv64-none" "rx-none" "s390-none" "s390x-none" "vc4-none"
|
||||
"x86_64-none"
|
||||
|
||||
# OpenBSD
|
||||
@ -74,6 +74,9 @@ in {
|
||||
mips = filterDoubles predicates.isMips;
|
||||
mmix = filterDoubles predicates.isMmix;
|
||||
riscv = filterDoubles predicates.isRiscV;
|
||||
riscv32 = filterDoubles predicates.isRiscV32;
|
||||
riscv64 = filterDoubles predicates.isRiscV64;
|
||||
rx = filterDoubles predicates.isRx;
|
||||
vc4 = filterDoubles predicates.isVc4;
|
||||
or1k = filterDoubles predicates.isOr1k;
|
||||
m68k = filterDoubles predicates.isM68k;
|
||||
|
||||
@ -79,8 +79,6 @@ rec {
|
||||
useLLVM = true;
|
||||
};
|
||||
|
||||
scaleway-c1 = armv7l-hf-multiplatform // platforms.scaleway-c1;
|
||||
|
||||
pogoplug4 = {
|
||||
config = "armv5tel-unknown-linux-gnueabi";
|
||||
} // platforms.pogoplug4;
|
||||
@ -145,6 +143,11 @@ rec {
|
||||
libc = "newlib";
|
||||
};
|
||||
|
||||
rx-embedded = {
|
||||
config = "rx-none-elf";
|
||||
libc = "newlib";
|
||||
};
|
||||
|
||||
msp430 = {
|
||||
config = "msp430-elf";
|
||||
libc = "newlib";
|
||||
@ -303,8 +306,6 @@ rec {
|
||||
|
||||
# BSDs
|
||||
|
||||
amd64-netbsd = lib.warn "The amd64-netbsd system example is deprecated. Use x86_64-netbsd instead." x86_64-netbsd;
|
||||
|
||||
x86_64-netbsd = {
|
||||
config = "x86_64-unknown-netbsd";
|
||||
libc = "nblibc";
|
||||
|
||||
29
lib/systems/flake-systems.nix
Normal file
29
lib/systems/flake-systems.nix
Normal file
@ -0,0 +1,29 @@
|
||||
# See [RFC 46] for mandated platform support and ../../pkgs/stdenv for
|
||||
# implemented platform support. This list is mainly descriptive, i.e. all
|
||||
# system doubles for platforms where nixpkgs can do native compiliation
|
||||
# reasonably well are included.
|
||||
#
|
||||
# [RFC 46]: https://github.com/NixOS/rfcs/blob/master/rfcs/0046-platform-support-tiers.md
|
||||
{ }:
|
||||
|
||||
[
|
||||
# Tier 1
|
||||
"x86_64-linux"
|
||||
# Tier 2
|
||||
"aarch64-linux"
|
||||
"x86_64-darwin"
|
||||
# Tier 3
|
||||
"armv6l-linux"
|
||||
"armv7l-linux"
|
||||
"i686-linux"
|
||||
"mipsel-linux"
|
||||
|
||||
# Other platforms with sufficient support in stdenv which is not formally
|
||||
# mandated by their platform tier.
|
||||
"aarch64-darwin"
|
||||
"armv5tel-linux"
|
||||
"powerpc64le-linux"
|
||||
"riscv64-linux"
|
||||
|
||||
# "x86_64-freebsd" is excluded because it is mostly broken
|
||||
]
|
||||
@ -11,8 +11,8 @@ rec {
|
||||
isi686 = { cpu = cpuTypes.i686; };
|
||||
isx86_32 = { cpu = { family = "x86"; bits = 32; }; };
|
||||
isx86_64 = { cpu = { family = "x86"; bits = 64; }; };
|
||||
isPowerPC = { cpu = cpuTypes.powerpc; };
|
||||
isPower = { cpu = { family = "power"; }; };
|
||||
isPower64 = { cpu = { family = "power"; bits = 64; }; };
|
||||
isx86 = { cpu = { family = "x86"; }; };
|
||||
isAarch32 = { cpu = { family = "arm"; bits = 32; }; };
|
||||
isAarch64 = { cpu = { family = "arm"; bits = 64; }; };
|
||||
@ -23,6 +23,9 @@ rec {
|
||||
isMips64n64 = { cpu = { family = "mips"; bits = 64; }; abi = { abi = "64"; }; };
|
||||
isMmix = { cpu = { family = "mmix"; }; };
|
||||
isRiscV = { cpu = { family = "riscv"; }; };
|
||||
isRiscV32 = { cpu = { family = "riscv"; bits = 32; }; };
|
||||
isRiscV64 = { cpu = { family = "riscv"; bits = 64; }; };
|
||||
isRx = { cpu = { family = "rx"; }; };
|
||||
isSparc = { cpu = { family = "sparc"; }; };
|
||||
isWasm = { cpu = { family = "wasm"; }; };
|
||||
isMsp430 = { cpu = { family = "msp430"; }; };
|
||||
|
||||
@ -116,6 +116,7 @@ rec {
|
||||
|
||||
alpha = { bits = 64; significantByte = littleEndian; family = "alpha"; };
|
||||
|
||||
rx = { bits = 32; significantByte = littleEndian; family = "rx"; };
|
||||
msp430 = { bits = 16; significantByte = littleEndian; family = "msp430"; };
|
||||
avr = { bits = 8; family = "avr"; };
|
||||
|
||||
@ -147,8 +148,10 @@ rec {
|
||||
# Every CPU is compatible with itself.
|
||||
# - (transitivity)
|
||||
# If A is compatible with B and B is compatible with C then A is compatible with C.
|
||||
# - (compatible under multiple endianness)
|
||||
# CPUs with multiple modes of endianness are pairwise compatible.
|
||||
#
|
||||
# Note: Since 22.11 the archs of a mode switching CPU are no longer considered
|
||||
# pairwise compatible. Mode switching implies that binaries built for A
|
||||
# and B respectively can't be executed at the same time.
|
||||
isCompatible = a: b: with cpuTypes; lib.any lib.id [
|
||||
# x86
|
||||
(b == i386 && isCompatible a i486)
|
||||
@ -190,22 +193,13 @@ rec {
|
||||
(b == aarch64 && a == armv8a)
|
||||
(b == armv8a && isCompatible a aarch64)
|
||||
|
||||
(b == aarch64 && a == aarch64_be)
|
||||
(b == aarch64_be && isCompatible a aarch64)
|
||||
|
||||
# PowerPC
|
||||
(b == powerpc && isCompatible a powerpc64)
|
||||
(b == powerpcle && isCompatible a powerpc)
|
||||
(b == powerpc && a == powerpcle)
|
||||
(b == powerpc64le && isCompatible a powerpc64)
|
||||
(b == powerpc64 && a == powerpc64le)
|
||||
(b == powerpcle && isCompatible a powerpc64le)
|
||||
|
||||
# MIPS
|
||||
(b == mips && isCompatible a mips64)
|
||||
(b == mips && a == mipsel)
|
||||
(b == mipsel && isCompatible a mips)
|
||||
(b == mips64 && a == mips64el)
|
||||
(b == mips64el && isCompatible a mips64)
|
||||
(b == mipsel && isCompatible a mips64el)
|
||||
|
||||
# RISCV
|
||||
(b == riscv32 && isCompatible a riscv64)
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
# targetPlatform, etc) containing at least the minimal set of attrs
|
||||
# required (see types.parsedPlatform in lib/systems/parse.nix). This
|
||||
# file takes an already-valid platform and further elaborates it with
|
||||
# optional fields such as linux-kernel, gcc, etc.
|
||||
# optional fields; currently these are: linux-kernel, gcc, and rustc.
|
||||
|
||||
{ lib }:
|
||||
rec {
|
||||
@ -242,13 +242,6 @@ rec {
|
||||
};
|
||||
};
|
||||
|
||||
scaleway-c1 = armv7l-hf-multiplatform // {
|
||||
gcc = {
|
||||
cpu = "cortex-a9";
|
||||
fpu = "vfpv3";
|
||||
};
|
||||
};
|
||||
|
||||
utilite = {
|
||||
linux-kernel = {
|
||||
name = "utilite";
|
||||
@ -568,5 +561,5 @@ rec {
|
||||
|
||||
else if platform.parsed.cpu == lib.systems.parse.cpuTypes.powerpc64le then powernv
|
||||
|
||||
else pc;
|
||||
else { };
|
||||
}
|
||||
|
||||
@ -1,26 +0,0 @@
|
||||
# Supported systems according to RFC0046's definition.
|
||||
#
|
||||
# https://github.com/NixOS/rfcs/blob/master/rfcs/0046-platform-support-tiers.md
|
||||
{ lib }:
|
||||
rec {
|
||||
# List of systems that are built by Hydra.
|
||||
hydra = tier1 ++ tier2 ++ tier3 ++ [
|
||||
"aarch64-darwin"
|
||||
];
|
||||
|
||||
tier1 = [
|
||||
"x86_64-linux"
|
||||
];
|
||||
|
||||
tier2 = [
|
||||
"aarch64-linux"
|
||||
"x86_64-darwin"
|
||||
];
|
||||
|
||||
tier3 = [
|
||||
"armv6l-linux"
|
||||
"armv7l-linux"
|
||||
"i686-linux"
|
||||
"mipsel-linux"
|
||||
];
|
||||
}
|
||||
31
lib/tests/maintainer-module.nix
Normal file
31
lib/tests/maintainer-module.nix
Normal file
@ -0,0 +1,31 @@
|
||||
{ lib, ... }:
|
||||
let
|
||||
inherit (lib) types;
|
||||
in {
|
||||
options = {
|
||||
name = lib.mkOption {
|
||||
type = types.str;
|
||||
};
|
||||
email = lib.mkOption {
|
||||
type = types.str;
|
||||
};
|
||||
matrix = lib.mkOption {
|
||||
type = types.nullOr types.str;
|
||||
default = null;
|
||||
};
|
||||
github = lib.mkOption {
|
||||
type = types.nullOr types.str;
|
||||
default = null;
|
||||
};
|
||||
githubId = lib.mkOption {
|
||||
type = types.nullOr types.ints.unsigned;
|
||||
default = null;
|
||||
};
|
||||
keys = lib.mkOption {
|
||||
type = types.listOf (types.submodule {
|
||||
options.fingerprint = lib.mkOption { type = types.str; };
|
||||
});
|
||||
default = [];
|
||||
};
|
||||
};
|
||||
}
|
||||
@ -1,50 +1,19 @@
|
||||
# to run these tests (and the others)
|
||||
# nix-build nixpkgs/lib/tests/release.nix
|
||||
{ # The pkgs used for dependencies for the testing itself
|
||||
pkgs
|
||||
, lib
|
||||
pkgs ? import ../.. {}
|
||||
, lib ? pkgs.lib
|
||||
}:
|
||||
|
||||
let
|
||||
inherit (lib) types;
|
||||
|
||||
maintainerModule = { config, ... }: {
|
||||
options = {
|
||||
name = lib.mkOption {
|
||||
type = types.str;
|
||||
};
|
||||
email = lib.mkOption {
|
||||
type = types.str;
|
||||
};
|
||||
matrix = lib.mkOption {
|
||||
type = types.nullOr types.str;
|
||||
default = null;
|
||||
};
|
||||
github = lib.mkOption {
|
||||
type = types.nullOr types.str;
|
||||
default = null;
|
||||
};
|
||||
githubId = lib.mkOption {
|
||||
type = types.nullOr types.ints.unsigned;
|
||||
default = null;
|
||||
};
|
||||
keys = lib.mkOption {
|
||||
type = types.listOf (types.submodule {
|
||||
options.longkeyid = lib.mkOption { type = types.str; };
|
||||
options.fingerprint = lib.mkOption { type = types.str; };
|
||||
});
|
||||
default = [];
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
checkMaintainer = handle: uncheckedAttrs:
|
||||
let
|
||||
prefix = [ "lib" "maintainers" handle ];
|
||||
checkedAttrs = (lib.modules.evalModules {
|
||||
inherit prefix;
|
||||
modules = [
|
||||
maintainerModule
|
||||
./maintainer-module.nix
|
||||
{
|
||||
_file = toString ../../maintainers/maintainer-list.nix;
|
||||
config = uncheckedAttrs;
|
||||
|
||||
@ -22,7 +22,6 @@ in
|
||||
|
||||
runTests {
|
||||
|
||||
|
||||
# TRIVIAL
|
||||
|
||||
testId = {
|
||||
@ -251,6 +250,68 @@ runTests {
|
||||
expected = ""test" 'test' < & >";
|
||||
};
|
||||
|
||||
testToShellVars = {
|
||||
expr = ''
|
||||
${toShellVars {
|
||||
STRing01 = "just a 'string'";
|
||||
_array_ = [ "with" "more strings" ];
|
||||
assoc."with some" = ''
|
||||
strings
|
||||
possibly newlines
|
||||
'';
|
||||
drv = {
|
||||
outPath = "/drv";
|
||||
foo = "ignored attribute";
|
||||
};
|
||||
path = /path;
|
||||
stringable = {
|
||||
__toString = _: "hello toString";
|
||||
bar = "ignored attribute";
|
||||
};
|
||||
}}
|
||||
'';
|
||||
expected = ''
|
||||
STRing01='just a '\'''string'\''''
|
||||
declare -a _array_=('with' 'more strings')
|
||||
declare -A assoc=(['with some']='strings
|
||||
possibly newlines
|
||||
')
|
||||
drv='/drv'
|
||||
path='/path'
|
||||
stringable='hello toString'
|
||||
'';
|
||||
};
|
||||
|
||||
testHasInfixFalse = {
|
||||
expr = hasInfix "c" "abde";
|
||||
expected = false;
|
||||
};
|
||||
|
||||
testHasInfixTrue = {
|
||||
expr = hasInfix "c" "abcde";
|
||||
expected = true;
|
||||
};
|
||||
|
||||
testHasInfixDerivation = {
|
||||
expr = hasInfix "hello" (import ../.. { system = "x86_64-linux"; }).hello;
|
||||
expected = true;
|
||||
};
|
||||
|
||||
testHasInfixPath = {
|
||||
expr = hasInfix "tests" ./.;
|
||||
expected = true;
|
||||
};
|
||||
|
||||
testHasInfixPathStoreDir = {
|
||||
expr = hasInfix builtins.storeDir ./.;
|
||||
expected = true;
|
||||
};
|
||||
|
||||
testHasInfixToString = {
|
||||
expr = hasInfix "a" { __toString = _: "a"; };
|
||||
expected = true;
|
||||
};
|
||||
|
||||
# LISTS
|
||||
|
||||
testFilter = {
|
||||
@ -613,6 +674,21 @@ runTests {
|
||||
expected = false;
|
||||
};
|
||||
|
||||
testWithRecursionDealsWithFunctors =
|
||||
let
|
||||
functor = {
|
||||
__functor = self: { a, b, }: null;
|
||||
};
|
||||
a = {
|
||||
value = "1234";
|
||||
b = functor;
|
||||
c.d = functor;
|
||||
};
|
||||
in {
|
||||
expr = generators.toPretty { } (generators.withRecursion { depthLimit = 1; throwOnDepthLimit = false; } a);
|
||||
expected = "{\n b = <function, args: {a, b}>;\n c = {\n d = \"<unevaluated>\";\n };\n value = \"<unevaluated>\";\n}";
|
||||
};
|
||||
|
||||
testToPrettyMultiline = {
|
||||
expr = mapAttrs (const (generators.toPretty { })) rec {
|
||||
list = [ 3 4 [ false ] ];
|
||||
|
||||
@ -194,6 +194,17 @@ checkConfigOutput '^"submodule"$' options.submodule.type.description ./declare-s
|
||||
## Paths should be allowed as values and work as expected
|
||||
checkConfigOutput '^true$' config.submodule.enable ./declare-submoduleWith-path.nix
|
||||
|
||||
## deferredModule
|
||||
# default module is merged into nodes.foo
|
||||
checkConfigOutput '"beta"' config.nodes.foo.settingsDict.c ./deferred-module.nix
|
||||
# errors from the default module are reported with accurate location
|
||||
checkConfigError 'In `the-file-that-contains-the-bad-config.nix, via option default'\'': "bogus"' config.nodes.foo.bottom ./deferred-module.nix
|
||||
checkConfigError '.*lib/tests/modules/deferred-module-error.nix, via option deferred [(]:anon-1:anon-1:anon-1[)] does not look like a module.' config.result ./deferred-module-error.nix
|
||||
|
||||
# Check the file location information is propagated into submodules
|
||||
checkConfigOutput the-file.nix config.submodule.internalFiles.0 ./submoduleFiles.nix
|
||||
|
||||
|
||||
# Check that disabledModules works recursively and correctly
|
||||
checkConfigOutput '^true$' config.enable ./disable-recursive/main.nix
|
||||
checkConfigOutput '^true$' config.enable ./disable-recursive/{main.nix,disable-foo.nix}
|
||||
@ -290,10 +301,12 @@ checkConfigOutput '^"a b"$' config.result ./functionTo/merging-list.nix
|
||||
checkConfigError 'A definition for option .fun.\[function body\]. is not of type .string.. Definition values:\n\s*- In .*wrong-type.nix' config.result ./functionTo/wrong-type.nix
|
||||
checkConfigOutput '^"b a"$' config.result ./functionTo/list-order.nix
|
||||
checkConfigOutput '^"a c"$' config.result ./functionTo/merging-attrs.nix
|
||||
checkConfigOutput '^"a bee"$' config.result ./functionTo/submodule-options.nix
|
||||
checkConfigOutput '^"fun.\[function body\].a fun.\[function body\].b"$' config.optionsResult ./functionTo/submodule-options.nix
|
||||
|
||||
# moduleType
|
||||
checkConfigOutput '^"a b"$' config.resultFoo ./declare-variants.nix ./define-variant.nix
|
||||
checkConfigOutput '^"a y z"$' config.resultFooBar ./declare-variants.nix ./define-variant.nix
|
||||
checkConfigOutput '^"a b y z"$' config.resultFooBar ./declare-variants.nix ./define-variant.nix
|
||||
checkConfigOutput '^"a b c"$' config.resultFooFoo ./declare-variants.nix ./define-variant.nix
|
||||
|
||||
## emptyValue's
|
||||
@ -313,7 +326,7 @@ checkConfigOutput "bar" config.priorities ./raw.nix
|
||||
|
||||
## Option collision
|
||||
checkConfigError \
|
||||
'The option .set. in module .*/declare-set.nix. would be a parent of the following options, but its type .attribute set of signed integers. does not support nested options.\n\s*- option[(]s[)] with prefix .set.enable. in module .*/declare-enable-nested.nix.' \
|
||||
'The option .set. in module .*/declare-set.nix. would be a parent of the following options, but its type .attribute set of signed integer. does not support nested options.\n\s*- option[(]s[)] with prefix .set.enable. in module .*/declare-enable-nested.nix.' \
|
||||
config.set \
|
||||
./declare-set.nix ./declare-enable-nested.nix
|
||||
|
||||
@ -327,6 +340,10 @@ checkConfigError 'The option .theOption.nested. in .other.nix. is already declar
|
||||
# Test that types.optionType leaves types untouched as long as they don't need to be merged
|
||||
checkConfigOutput 'ok' config.freeformItems.foo.bar ./adhoc-freeformType-survives-type-merge.nix
|
||||
|
||||
# Anonymous submodules don't get nixed by import resolution/deduplication
|
||||
# because of an `extendModules` bug, issue 168767.
|
||||
checkConfigOutput '^1$' config.sub.specialisation.value ./extendModules-168767-imports.nix
|
||||
|
||||
cat <<EOF
|
||||
====== module tests ======
|
||||
$pass Pass
|
||||
|
||||
20
lib/tests/modules/deferred-module-error.nix
Normal file
20
lib/tests/modules/deferred-module-error.nix
Normal file
@ -0,0 +1,20 @@
|
||||
{ config, lib, ... }:
|
||||
let
|
||||
inherit (lib) types mkOption setDefaultModuleLocation evalModules;
|
||||
inherit (types) deferredModule lazyAttrsOf submodule str raw enum;
|
||||
in
|
||||
{
|
||||
options = {
|
||||
deferred = mkOption {
|
||||
type = deferredModule;
|
||||
};
|
||||
result = mkOption {
|
||||
default = (evalModules { modules = [ config.deferred ]; }).config.result;
|
||||
};
|
||||
};
|
||||
config = {
|
||||
deferred = { ... }:
|
||||
# this should be an attrset, so this fails
|
||||
true;
|
||||
};
|
||||
}
|
||||
58
lib/tests/modules/deferred-module.nix
Normal file
58
lib/tests/modules/deferred-module.nix
Normal file
@ -0,0 +1,58 @@
|
||||
{ lib, ... }:
|
||||
let
|
||||
inherit (lib) types mkOption setDefaultModuleLocation;
|
||||
inherit (types) deferredModule lazyAttrsOf submodule str raw enum;
|
||||
in
|
||||
{
|
||||
imports = [
|
||||
# generic module, declaring submodules:
|
||||
# - nodes.<name>
|
||||
# - default
|
||||
# where all nodes include the default
|
||||
({ config, ... }: {
|
||||
_file = "generic.nix";
|
||||
options.nodes = mkOption {
|
||||
type = lazyAttrsOf (submodule { imports = [ config.default ]; });
|
||||
default = {};
|
||||
};
|
||||
options.default = mkOption {
|
||||
type = deferredModule;
|
||||
default = { };
|
||||
description = ''
|
||||
Module that is included in all nodes.
|
||||
'';
|
||||
};
|
||||
})
|
||||
|
||||
{
|
||||
_file = "default-1.nix";
|
||||
default = { config, ... }: {
|
||||
options.settingsDict = lib.mkOption { type = lazyAttrsOf str; default = {}; };
|
||||
options.bottom = lib.mkOption { type = enum []; };
|
||||
};
|
||||
}
|
||||
|
||||
{
|
||||
_file = "default-a-is-b.nix";
|
||||
default = ./define-settingsDict-a-is-b.nix;
|
||||
}
|
||||
|
||||
{
|
||||
_file = "nodes-foo.nix";
|
||||
nodes.foo.settingsDict.b = "beta";
|
||||
}
|
||||
|
||||
{
|
||||
_file = "the-file-that-contains-the-bad-config.nix";
|
||||
default.bottom = "bogus";
|
||||
}
|
||||
|
||||
{
|
||||
_file = "nodes-foo-c-is-a.nix";
|
||||
nodes.foo = { config, ... }: {
|
||||
settingsDict.c = config.settingsDict.a;
|
||||
};
|
||||
}
|
||||
|
||||
];
|
||||
}
|
||||
3
lib/tests/modules/define-settingsDict-a-is-b.nix
Normal file
3
lib/tests/modules/define-settingsDict-a-is-b.nix
Normal file
@ -0,0 +1,3 @@
|
||||
{ config, ... }: {
|
||||
settingsDict.a = config.settingsDict.b;
|
||||
}
|
||||
41
lib/tests/modules/extendModules-168767-imports.nix
Normal file
41
lib/tests/modules/extendModules-168767-imports.nix
Normal file
@ -0,0 +1,41 @@
|
||||
{ lib
|
||||
, extendModules
|
||||
, ...
|
||||
}:
|
||||
with lib;
|
||||
{
|
||||
imports = [
|
||||
|
||||
{
|
||||
options.sub = mkOption {
|
||||
default = { };
|
||||
type = types.submodule (
|
||||
{ config
|
||||
, extendModules
|
||||
, ...
|
||||
}:
|
||||
{
|
||||
options.value = mkOption {
|
||||
type = types.int;
|
||||
};
|
||||
|
||||
options.specialisation = mkOption {
|
||||
default = { };
|
||||
inherit
|
||||
(extendModules {
|
||||
modules = [{
|
||||
specialisation = mkOverride 0 { };
|
||||
}];
|
||||
})
|
||||
type;
|
||||
};
|
||||
}
|
||||
);
|
||||
};
|
||||
}
|
||||
|
||||
{ config.sub.value = 1; }
|
||||
|
||||
|
||||
];
|
||||
}
|
||||
61
lib/tests/modules/functionTo/submodule-options.nix
Normal file
61
lib/tests/modules/functionTo/submodule-options.nix
Normal file
@ -0,0 +1,61 @@
|
||||
{ lib, config, options, ... }:
|
||||
let
|
||||
inherit (lib) types;
|
||||
in
|
||||
{
|
||||
imports = [
|
||||
|
||||
# fun.<function-body>.a
|
||||
({ ... }: {
|
||||
options = {
|
||||
fun = lib.mkOption {
|
||||
type = types.functionTo (types.submodule {
|
||||
options.a = lib.mkOption { default = "a"; };
|
||||
});
|
||||
};
|
||||
};
|
||||
})
|
||||
|
||||
# fun.<function-body>.b
|
||||
({ ... }: {
|
||||
options = {
|
||||
fun = lib.mkOption {
|
||||
type = types.functionTo (types.submodule {
|
||||
options.b = lib.mkOption { default = "b"; };
|
||||
});
|
||||
};
|
||||
};
|
||||
})
|
||||
];
|
||||
|
||||
options = {
|
||||
result = lib.mkOption
|
||||
{
|
||||
type = types.str;
|
||||
default = lib.concatStringsSep " " (lib.attrValues (config.fun (throw "shouldn't use input param")));
|
||||
};
|
||||
|
||||
optionsResult = lib.mkOption
|
||||
{
|
||||
type = types.str;
|
||||
default = lib.concatStringsSep " "
|
||||
(lib.concatLists
|
||||
(lib.mapAttrsToList
|
||||
(k: v:
|
||||
if k == "_module"
|
||||
then [ ]
|
||||
else [ (lib.showOption v.loc) ]
|
||||
)
|
||||
(
|
||||
(options.fun.type.getSubOptions [ "fun" ])
|
||||
)
|
||||
)
|
||||
);
|
||||
};
|
||||
};
|
||||
|
||||
config.fun = lib.mkMerge
|
||||
[
|
||||
(input: { b = "bee"; })
|
||||
];
|
||||
}
|
||||
21
lib/tests/modules/submoduleFiles.nix
Normal file
21
lib/tests/modules/submoduleFiles.nix
Normal file
@ -0,0 +1,21 @@
|
||||
{ lib, ... }: {
|
||||
options.submodule = lib.mkOption {
|
||||
default = {};
|
||||
type = lib.types.submoduleWith {
|
||||
modules = [ ({ options, ... }: {
|
||||
options.value = lib.mkOption {};
|
||||
|
||||
options.internalFiles = lib.mkOption {
|
||||
default = options.value.files;
|
||||
};
|
||||
})];
|
||||
};
|
||||
};
|
||||
|
||||
imports = [
|
||||
{
|
||||
_file = "the-file.nix";
|
||||
submodule.value = 10;
|
||||
}
|
||||
];
|
||||
}
|
||||
@ -11,6 +11,10 @@ pkgs.runCommand "nixpkgs-lib-tests" {
|
||||
inherit pkgs;
|
||||
lib = import ../.;
|
||||
})
|
||||
(import ./teams.nix {
|
||||
inherit pkgs;
|
||||
lib = import ../.;
|
||||
})
|
||||
];
|
||||
} ''
|
||||
datadir="${pkgs.nix}/share"
|
||||
|
||||
@ -19,6 +19,9 @@ with lib.systems.doubles; lib.runTests {
|
||||
testi686 = mseteq i686 [ "i686-linux" "i686-freebsd" "i686-genode" "i686-netbsd" "i686-openbsd" "i686-cygwin" "i686-windows" "i686-none" "i686-darwin" ];
|
||||
testmips = mseteq mips [ "mips64el-linux" "mipsel-linux" "mipsel-netbsd" ];
|
||||
testmmix = mseteq mmix [ "mmix-mmixware" ];
|
||||
testriscv = mseteq riscv [ "riscv32-linux" "riscv64-linux" "riscv32-netbsd" "riscv64-netbsd" "riscv32-none" "riscv64-none" ];
|
||||
testriscv32 = mseteq riscv32 [ "riscv32-linux" "riscv32-netbsd" "riscv32-none" ];
|
||||
testriscv64 = mseteq riscv64 [ "riscv64-linux" "riscv64-netbsd" "riscv64-none" ];
|
||||
testx86_64 = mseteq x86_64 [ "x86_64-linux" "x86_64-darwin" "x86_64-freebsd" "x86_64-genode" "x86_64-redox" "x86_64-openbsd" "x86_64-netbsd" "x86_64-cygwin" "x86_64-solaris" "x86_64-windows" "x86_64-none" ];
|
||||
|
||||
testcygwin = mseteq cygwin [ "i686-cygwin" "x86_64-cygwin" ];
|
||||
|
||||
50
lib/tests/teams.nix
Normal file
50
lib/tests/teams.nix
Normal file
@ -0,0 +1,50 @@
|
||||
# to run these tests:
|
||||
# nix-build nixpkgs/lib/tests/teams.nix
|
||||
# If it builds, all tests passed
|
||||
{ pkgs ? import ../.. {}, lib ? pkgs.lib }:
|
||||
|
||||
let
|
||||
inherit (lib) types;
|
||||
|
||||
teamModule = { config, ... }: {
|
||||
options = {
|
||||
shortName = lib.mkOption {
|
||||
type = types.str;
|
||||
};
|
||||
scope = lib.mkOption {
|
||||
type = types.str;
|
||||
};
|
||||
enableFeatureFreezePing = lib.mkOption {
|
||||
type = types.bool;
|
||||
default = false;
|
||||
};
|
||||
members = lib.mkOption {
|
||||
type = types.listOf (types.submodule
|
||||
(import ./maintainer-module.nix { inherit lib; })
|
||||
);
|
||||
default = [];
|
||||
};
|
||||
githubTeams = lib.mkOption {
|
||||
type = types.listOf types.str;
|
||||
default = [];
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
checkTeam = team: uncheckedAttrs:
|
||||
let
|
||||
prefix = [ "lib" "maintainer-team" team ];
|
||||
checkedAttrs = (lib.modules.evalModules {
|
||||
inherit prefix;
|
||||
modules = [
|
||||
teamModule
|
||||
{
|
||||
_file = toString ../../maintainers/team-list.nix;
|
||||
config = uncheckedAttrs;
|
||||
}
|
||||
];
|
||||
}).config;
|
||||
in checkedAttrs;
|
||||
|
||||
checkedTeams = lib.mapAttrs checkTeam lib.teams;
|
||||
in pkgs.writeTextDir "maintainer-teams.json" (builtins.toJSON checkedTeams)
|
||||
@ -195,7 +195,7 @@ rec {
|
||||
On each release the first letter is bumped and a new animal is chosen
|
||||
starting with that new letter.
|
||||
*/
|
||||
codeName = "Quokka";
|
||||
codeName = "Raccoon";
|
||||
|
||||
/* Returns the current nixpkgs version suffix as string. */
|
||||
versionSuffix =
|
||||
@ -229,6 +229,13 @@ rec {
|
||||
*/
|
||||
inNixShell = builtins.getEnv "IN_NIX_SHELL" != "";
|
||||
|
||||
/* Determine whether the function is being called from inside pure-eval mode
|
||||
by seeing whether `builtins` contains `currentSystem`. If not, we must be in
|
||||
pure-eval mode.
|
||||
|
||||
Type: inPureEvalMode :: bool
|
||||
*/
|
||||
inPureEvalMode = ! builtins ? currentSystem;
|
||||
|
||||
## Integer operations
|
||||
|
||||
|
||||
@ -397,7 +397,7 @@ rec {
|
||||
|
||||
listOf = elemType: mkOptionType rec {
|
||||
name = "listOf";
|
||||
description = "list of ${elemType.description}s";
|
||||
description = "list of ${elemType.description}";
|
||||
check = isList;
|
||||
merge = loc: defs:
|
||||
map (x: x.value) (filter (x: x ? value) (concatLists (imap1 (n: def:
|
||||
@ -426,7 +426,7 @@ rec {
|
||||
|
||||
attrsOf = elemType: mkOptionType rec {
|
||||
name = "attrsOf";
|
||||
description = "attribute set of ${elemType.description}s";
|
||||
description = "attribute set of ${elemType.description}";
|
||||
check = isAttrs;
|
||||
merge = loc: defs:
|
||||
mapAttrs (n: v: v.value) (filterAttrs (n: v: v ? value) (zipAttrsWith (name: defs:
|
||||
@ -449,7 +449,7 @@ rec {
|
||||
# error that it's not defined. Use only if conditional definitions don't make sense.
|
||||
lazyAttrsOf = elemType: mkOptionType rec {
|
||||
name = "lazyAttrsOf";
|
||||
description = "lazy attribute set of ${elemType.description}s";
|
||||
description = "lazy attribute set of ${elemType.description}";
|
||||
check = isAttrs;
|
||||
merge = loc: defs:
|
||||
zipAttrsWith (name: defs:
|
||||
@ -526,9 +526,11 @@ rec {
|
||||
check = isFunction;
|
||||
merge = loc: defs:
|
||||
fnArgs: (mergeDefinitions (loc ++ [ "[function body]" ]) elemType (map (fn: { inherit (fn) file; value = fn.value fnArgs; }) defs)).mergedValue;
|
||||
getSubOptions = elemType.getSubOptions;
|
||||
getSubOptions = prefix: elemType.getSubOptions (prefix ++ [ "[function body]" ]);
|
||||
getSubModules = elemType.getSubModules;
|
||||
substSubModules = m: functionTo (elemType.substSubModules m);
|
||||
functor = (defaultFunctor "functionTo") // { wrapped = elemType; };
|
||||
nestedTypes.elemType = elemType;
|
||||
};
|
||||
|
||||
# A submodule (like typed attribute set). See NixOS manual.
|
||||
@ -537,6 +539,36 @@ rec {
|
||||
modules = toList modules;
|
||||
};
|
||||
|
||||
# A module to be imported in some other part of the configuration.
|
||||
deferredModule = deferredModuleWith { };
|
||||
|
||||
# A module to be imported in some other part of the configuration.
|
||||
# `staticModules`' options will be added to the documentation, unlike
|
||||
# options declared via `config`.
|
||||
deferredModuleWith = attrs@{ staticModules ? [] }: mkOptionType {
|
||||
name = "deferredModule";
|
||||
description = "module";
|
||||
check = x: isAttrs x || isFunction x || path.check x;
|
||||
merge = loc: defs: {
|
||||
imports = staticModules ++ map (def: lib.setDefaultModuleLocation "${def.file}, via option ${showOption loc}" def.value) defs;
|
||||
};
|
||||
inherit (submoduleWith { modules = staticModules; })
|
||||
getSubOptions
|
||||
getSubModules;
|
||||
substSubModules = m: deferredModuleWith (attrs // {
|
||||
staticModules = m;
|
||||
});
|
||||
functor = defaultFunctor "deferredModuleWith" // {
|
||||
type = types.deferredModuleWith;
|
||||
payload = {
|
||||
inherit staticModules;
|
||||
};
|
||||
binOp = lhs: rhs: {
|
||||
staticModules = lhs.staticModules ++ rhs.staticModules;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
# The type of a type!
|
||||
optionType = mkOptionType {
|
||||
name = "optionType";
|
||||
@ -568,23 +600,15 @@ rec {
|
||||
{ modules
|
||||
, specialArgs ? {}
|
||||
, shorthandOnlyDefinesConfig ? false
|
||||
, description ? null
|
||||
}@attrs:
|
||||
let
|
||||
inherit (lib.modules) evalModules;
|
||||
|
||||
shorthandToModule = if shorthandOnlyDefinesConfig == false
|
||||
then value: value
|
||||
else value: { config = value; };
|
||||
|
||||
allModules = defs: imap1 (n: { value, file }:
|
||||
if isFunction value
|
||||
then setFunctionArgs
|
||||
(args: lib.modules.unifyModuleSyntax file "${toString file}-${toString n}" (value args))
|
||||
(functionArgs value)
|
||||
else if isAttrs value
|
||||
then
|
||||
lib.modules.unifyModuleSyntax file "${toString file}-${toString n}" (shorthandToModule value)
|
||||
else value
|
||||
allModules = defs: map ({ value, file }:
|
||||
if isAttrs value && shorthandOnlyDefinesConfig
|
||||
then { _file = file; config = value; }
|
||||
else { _file = file; imports = [ value ]; }
|
||||
) defs;
|
||||
|
||||
base = evalModules {
|
||||
@ -611,10 +635,14 @@ rec {
|
||||
|
||||
freeformType = base._module.freeformType;
|
||||
|
||||
in
|
||||
mkOptionType rec {
|
||||
name = "submodule";
|
||||
description = freeformType.description or name;
|
||||
|
||||
in
|
||||
mkOptionType {
|
||||
inherit name;
|
||||
description =
|
||||
if description != null then description
|
||||
else freeformType.description or name;
|
||||
check = x: isAttrs x || isFunction x || path.check x;
|
||||
merge = loc: defs:
|
||||
(base.extendModules {
|
||||
@ -639,9 +667,7 @@ rec {
|
||||
functor = defaultFunctor name // {
|
||||
type = types.submoduleWith;
|
||||
payload = {
|
||||
modules = modules;
|
||||
specialArgs = specialArgs;
|
||||
shorthandOnlyDefinesConfig = shorthandOnlyDefinesConfig;
|
||||
inherit modules specialArgs shorthandOnlyDefinesConfig description;
|
||||
};
|
||||
binOp = lhs: rhs: {
|
||||
modules = lhs.modules ++ rhs.modules;
|
||||
@ -658,6 +684,14 @@ rec {
|
||||
else if lhs.shorthandOnlyDefinesConfig == rhs.shorthandOnlyDefinesConfig
|
||||
then lhs.shorthandOnlyDefinesConfig
|
||||
else throw "A submoduleWith option is declared multiple times with conflicting shorthandOnlyDefinesConfig values";
|
||||
description =
|
||||
if lhs.description == null
|
||||
then rhs.description
|
||||
else if rhs.description == null
|
||||
then lhs.description
|
||||
else if lhs.description == rhs.description
|
||||
then lhs.description
|
||||
else throw "A submoduleWith option is declared multiple times with conflicting descriptions";
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
/* Helper function to implement a fallback for the bit operators
|
||||
`bitAnd`, `bitOr` and `bitXOr` on older nix version.
|
||||
`bitAnd`, `bitOr` and `bitXor` on older nix version.
|
||||
See ./trivial.nix
|
||||
*/
|
||||
f: x: y:
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
52
maintainers/scripts/fix-maintainers.pl
Executable file
52
maintainers/scripts/fix-maintainers.pl
Executable file
@ -0,0 +1,52 @@
|
||||
#!/usr/bin/env nix-shell
|
||||
#!nix-shell -i perl -p perl -p perlPackages.LWP -p perlPackages.LWPProtocolHttps -p perlPackages.LWPUserAgent -p perlPackages.JSON -p perlPackages.PathTiny
|
||||
use LWP::UserAgent;
|
||||
use JSON;
|
||||
use Path::Tiny;
|
||||
use strict;
|
||||
use warnings;
|
||||
|
||||
my $maintainers_list_nix = "../maintainer-list.nix";
|
||||
my $maintainers_json = from_json(`nix-instantiate --json --eval --expr 'builtins.fromJSON (builtins.toJSON (import $maintainers_list_nix))'`);
|
||||
|
||||
STDOUT->autoflush(1);
|
||||
|
||||
my $ua = LWP::UserAgent->new();
|
||||
|
||||
keys %$maintainers_json; # reset the internal iterator so a prior each() doesn't affect the loop
|
||||
while(my($k, $v) = each %$maintainers_json) {
|
||||
my $current_user = %$v{'github'};
|
||||
if (!defined $current_user) {
|
||||
print "$k has no github handle\n";
|
||||
next;
|
||||
}
|
||||
my $github_id = %$v{'githubId'};
|
||||
if (!defined $github_id) {
|
||||
print "$k has no githubId\n";
|
||||
next;
|
||||
}
|
||||
my $url = 'https://api.github.com/user/' . $github_id;
|
||||
my $resp = $ua->get(
|
||||
$url,
|
||||
"Authorization" => "Token $ENV{GH_TOKEN}"
|
||||
);
|
||||
|
||||
if ($resp->header("X-RateLimit-Remaining") == 0) {
|
||||
my $ratelimit_reset = $resp->header("X-RateLimit-Reset");
|
||||
print "Request limit exceeded, waiting until " . scalar localtime $ratelimit_reset . "\n";
|
||||
sleep($ratelimit_reset - time() + 5);
|
||||
}
|
||||
if ($resp->code != 200) {
|
||||
print $current_user . " likely deleted their github account\n";
|
||||
next;
|
||||
}
|
||||
my $resp_json = from_json($resp->content);
|
||||
my $api_user = %$resp_json{"login"};
|
||||
if ($current_user ne $api_user) {
|
||||
print $current_user . " is now known on github as " . $api_user . ". Editing maintainer-list.nix…\n";
|
||||
my $file = path($maintainers_list_nix);
|
||||
my $data = $file->slurp_utf8;
|
||||
$data =~ s/github = "$current_user";$/github = "$api_user";/m;
|
||||
$file->spew_utf8($data);
|
||||
}
|
||||
}
|
||||
@ -20,14 +20,12 @@ Because step 1) is quite expensive and takes roughly ~5 minutes the result is ca
|
||||
{-# LANGUAGE DerivingStrategies #-}
|
||||
{-# LANGUAGE DuplicateRecordFields #-}
|
||||
{-# LANGUAGE LambdaCase #-}
|
||||
{-# LANGUAGE MultiWayIf #-}
|
||||
{-# LANGUAGE NamedFieldPuns #-}
|
||||
{-# LANGUAGE OverloadedStrings #-}
|
||||
{-# LANGUAGE ScopedTypeVariables #-}
|
||||
{-# LANGUAGE TupleSections #-}
|
||||
{-# OPTIONS_GHC -Wall #-}
|
||||
{-# LANGUAGE ViewPatterns #-}
|
||||
{-# LANGUAGE TupleSections #-}
|
||||
{-# OPTIONS_GHC -Wall #-}
|
||||
|
||||
import Control.Monad (forM_, (<=<))
|
||||
import Control.Monad.Trans (MonadIO (liftIO))
|
||||
|
||||
@ -1,4 +1,8 @@
|
||||
|
||||
-- default of luarocks listed at src/luarocks/core/cfg.lua
|
||||
-- keep this list synced with pkgs/build-support/fetchurl/mirrors.nix
|
||||
rocks_servers = {
|
||||
"https://luarocks.org"
|
||||
"https://luarocks.org",
|
||||
"https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/"
|
||||
}
|
||||
version_check_on_fail = false
|
||||
|
||||
@ -6,6 +6,7 @@ basexx,https://github.com/teto/basexx.git,,,,,
|
||||
binaryheap,https://github.com/Tieske/binaryheap.lua,,,,,vcunat
|
||||
busted,,,,,,
|
||||
cassowary,,,,,,marsam alerque
|
||||
cldr,,,,,,alerque
|
||||
compat53,,,,0.7-1,,vcunat
|
||||
cosmo,,,,,,marsam
|
||||
coxpcall,,,,1.17.0-1,,
|
||||
@ -14,6 +15,7 @@ cyrussasl,https://github.com/JorjBauer/lua-cyrussasl.git,,,,,
|
||||
digestif,https://github.com/astoff/digestif.git,,,0.2-1,lua5_3,
|
||||
dkjson,,,,,,
|
||||
fifo,,,,,,
|
||||
fluent,,,,,,alerque
|
||||
gitsigns.nvim,https://github.com/lewis6991/gitsigns.nvim.git,,,,lua5_1,
|
||||
http,,,,0.3-0,,vcunat
|
||||
inspect,,,,,,
|
||||
@ -22,6 +24,9 @@ ldoc,https://github.com/stevedonovan/LDoc.git,,,,,
|
||||
lgi,,,,,,
|
||||
linenoise,https://github.com/hoelzro/lua-linenoise.git,,,,,
|
||||
ljsyscall,,,,,lua5_1,lblasc
|
||||
lmathx,,,,,lua5_3,alexshpilkin
|
||||
lmpfrlib,,,,,lua5_3,alexshpilkin
|
||||
loadkit,,,,,,alerque
|
||||
lpeg,,,,,,vyp
|
||||
lpeg_patterns,,,,,,
|
||||
lpeglabel,,,,,,
|
||||
@ -52,7 +57,7 @@ luadbi-postgresql,,,,,,
|
||||
luadbi-sqlite3,,,,,,
|
||||
luaepnf,,,,,,
|
||||
luaevent,,,,,,
|
||||
luaexpat,,,,1.3.0-1,,arobyn flosse
|
||||
luaexpat,,,,1.4.1-1,,arobyn flosse
|
||||
luaffi,,,http://luarocks.org/dev,,,
|
||||
luafilesystem,,,,1.7.0-2,,flosse
|
||||
lualogging,,,,,,
|
||||
@ -64,6 +69,7 @@ luasocket,,,,,,
|
||||
luasql-sqlite3,,,,,,vyp
|
||||
luassert,,,,,,
|
||||
luasystem,,,,,,
|
||||
luaunbound,,,,,
|
||||
luautf8,,,,,,pstn
|
||||
luazip,,,,,,
|
||||
lua-yajl,,,,,,pstn
|
||||
@ -80,7 +86,9 @@ plenary.nvim,https://github.com/nvim-lua/plenary.nvim.git,,,,lua5_1,
|
||||
rapidjson,https://github.com/xpol/lua-rapidjson.git,,,,,
|
||||
readline,,,,,,
|
||||
say,https://github.com/Olivine-Labs/say.git,,,,,
|
||||
sqlite,,,,,,
|
||||
std._debug,https://github.com/lua-stdlib/_debug.git,,,,,
|
||||
std.normalize,https://github.com/lua-stdlib/normalize.git,,,,,
|
||||
stdlib,,,,41.2.2,,vyp
|
||||
tl,,,,,,mephistophiles
|
||||
vstruct,https://github.com/ToxicFrog/vstruct.git,,,,,
|
||||
|
||||
|
Can't render this file because it has a wrong number of fields in line 72.
|
@ -61,7 +61,7 @@ for bin in $(find $binaryDist -executable -type f) :; do
|
||||
uniq;
|
||||
)
|
||||
|
||||
if test "$names" = "glibc"; then names="stdenv.glibc"; fi
|
||||
if test "$names" = "glibc"; then names="glibc"; fi
|
||||
if echo $names | grep -c "gcc" &> /dev/null; then names="stdenv.cc.cc"; fi
|
||||
|
||||
if test $lib != $libPath; then
|
||||
|
||||
@ -87,7 +87,8 @@ def make_request(url: str, token=None) -> urllib.request.Request:
|
||||
return urllib.request.Request(url, headers=headers)
|
||||
|
||||
|
||||
Redirects = Dict['Repo', 'Repo']
|
||||
# a dictionary of plugins and their new repositories
|
||||
Redirects = Dict['PluginDesc', 'Repo']
|
||||
|
||||
class Repo:
|
||||
def __init__(
|
||||
@ -96,8 +97,8 @@ class Repo:
|
||||
self.uri = uri
|
||||
'''Url to the repo'''
|
||||
self._branch = branch
|
||||
# {old_uri: new_uri}
|
||||
self.redirect: Redirects = {}
|
||||
# Redirect is the new Repo to use
|
||||
self.redirect: Optional['Repo'] = None
|
||||
self.token = "dummy_token"
|
||||
|
||||
@property
|
||||
@ -207,7 +208,7 @@ class RepoGitHub(Repo):
|
||||
)
|
||||
|
||||
new_repo = RepoGitHub(owner=new_owner, repo=new_name, branch=self.branch)
|
||||
self.redirect[self] = new_repo
|
||||
self.redirect = new_repo
|
||||
|
||||
|
||||
def prefetch(self, commit: str) -> str:
|
||||
@ -237,7 +238,7 @@ class RepoGitHub(Repo):
|
||||
}}'''
|
||||
|
||||
|
||||
@dataclass
|
||||
@dataclass(frozen=True)
|
||||
class PluginDesc:
|
||||
repo: Repo
|
||||
branch: str
|
||||
@ -310,6 +311,16 @@ def load_plugins_from_csv(config: FetchConfig, input_file: Path,) -> List[Plugin
|
||||
|
||||
return plugins
|
||||
|
||||
def run_nix_expr(expr):
|
||||
with CleanEnvironment():
|
||||
cmd = ["nix", "eval", "--extra-experimental-features",
|
||||
"nix-command", "--impure", "--json", "--expr", expr]
|
||||
log.debug("Running command %s", cmd)
|
||||
out = subprocess.check_output(cmd)
|
||||
data = json.loads(out)
|
||||
return data
|
||||
|
||||
|
||||
class Editor:
|
||||
"""The configuration of the update script."""
|
||||
|
||||
@ -332,9 +343,15 @@ class Editor:
|
||||
self.deprecated = deprecated or root.joinpath("deprecated.json")
|
||||
self.cache_file = cache_file or f"{name}-plugin-cache.json"
|
||||
|
||||
def get_current_plugins(self):
|
||||
def get_current_plugins(self) -> List[Plugin]:
|
||||
"""To fill the cache"""
|
||||
return get_current_plugins(self)
|
||||
data = run_nix_expr(self.get_plugins)
|
||||
plugins = []
|
||||
for name, attr in data.items():
|
||||
print("get_current_plugins: name %s" % name)
|
||||
p = Plugin(name, attr["rev"], attr["submodules"], attr["sha256"])
|
||||
plugins.append(p)
|
||||
return plugins
|
||||
|
||||
def load_plugin_spec(self, config: FetchConfig, plugin_file) -> List[PluginDesc]:
|
||||
'''CSV spec'''
|
||||
@ -448,24 +465,10 @@ class CleanEnvironment(object):
|
||||
self.empty_config.close()
|
||||
|
||||
|
||||
def get_current_plugins(editor: Editor) -> List[Plugin]:
|
||||
with CleanEnvironment():
|
||||
cmd = ["nix", "eval", "--extra-experimental-features", "nix-command", "--impure", "--json", "--expr", editor.get_plugins]
|
||||
log.debug("Running command %s", cmd)
|
||||
out = subprocess.check_output(cmd)
|
||||
data = json.loads(out)
|
||||
plugins = []
|
||||
for name, attr in data.items():
|
||||
print("get_current_plugins: name %s" % name)
|
||||
p = Plugin(name, attr["rev"], attr["submodules"], attr["sha256"])
|
||||
plugins.append(p)
|
||||
return plugins
|
||||
|
||||
|
||||
def prefetch_plugin(
|
||||
p: PluginDesc,
|
||||
cache: "Optional[Cache]" = None,
|
||||
) -> Tuple[Plugin, Redirects]:
|
||||
) -> Tuple[Plugin, Optional[Repo]]:
|
||||
repo, branch, alias = p.repo, p.branch, p.alias
|
||||
name = alias or p.repo.name
|
||||
commit = None
|
||||
@ -479,7 +482,7 @@ def prefetch_plugin(
|
||||
return cached_plugin, repo.redirect
|
||||
|
||||
has_submodules = repo.has_submodules()
|
||||
print(f"prefetch {name}")
|
||||
log.debug(f"prefetch {name}")
|
||||
sha256 = repo.prefetch(commit)
|
||||
|
||||
return (
|
||||
@ -488,7 +491,7 @@ def prefetch_plugin(
|
||||
)
|
||||
|
||||
|
||||
def print_download_error(plugin: str, ex: Exception):
|
||||
def print_download_error(plugin: PluginDesc, ex: Exception):
|
||||
print(f"{plugin}: {ex}", file=sys.stderr)
|
||||
ex_traceback = ex.__traceback__
|
||||
tb_lines = [
|
||||
@ -498,19 +501,21 @@ def print_download_error(plugin: str, ex: Exception):
|
||||
print("\n".join(tb_lines))
|
||||
|
||||
def check_results(
|
||||
results: List[Tuple[PluginDesc, Union[Exception, Plugin], Redirects]]
|
||||
results: List[Tuple[PluginDesc, Union[Exception, Plugin], Optional[Repo]]]
|
||||
) -> Tuple[List[Tuple[PluginDesc, Plugin]], Redirects]:
|
||||
''' '''
|
||||
failures: List[Tuple[str, Exception]] = []
|
||||
failures: List[Tuple[PluginDesc, Exception]] = []
|
||||
plugins = []
|
||||
# {old: new} plugindesc
|
||||
redirects: Dict[Repo, Repo] = {}
|
||||
redirects: Redirects = {}
|
||||
for (pdesc, result, redirect) in results:
|
||||
if isinstance(result, Exception):
|
||||
failures.append((pdesc.name, result))
|
||||
failures.append((pdesc, result))
|
||||
else:
|
||||
plugins.append((pdesc, result))
|
||||
redirects.update(redirect)
|
||||
new_pdesc = pdesc
|
||||
if redirect is not None:
|
||||
redirects.update({pdesc: redirect})
|
||||
new_pdesc = PluginDesc(redirect, pdesc.branch, pdesc.alias)
|
||||
plugins.append((new_pdesc, result))
|
||||
|
||||
print(f"{len(results) - len(failures)} plugins were checked", end="")
|
||||
if len(failures) == 0:
|
||||
@ -591,13 +596,13 @@ class Cache:
|
||||
|
||||
def prefetch(
|
||||
pluginDesc: PluginDesc, cache: Cache
|
||||
) -> Tuple[PluginDesc, Union[Exception, Plugin], dict]:
|
||||
) -> Tuple[PluginDesc, Union[Exception, Plugin], Optional[Repo]]:
|
||||
try:
|
||||
plugin, redirect = prefetch_plugin(pluginDesc, cache)
|
||||
cache[plugin.commit] = plugin
|
||||
return (pluginDesc, plugin, redirect)
|
||||
except Exception as e:
|
||||
return (pluginDesc, e, {})
|
||||
return (pluginDesc, e, None)
|
||||
|
||||
|
||||
|
||||
@ -606,7 +611,7 @@ def rewrite_input(
|
||||
input_file: Path,
|
||||
deprecated: Path,
|
||||
# old pluginDesc and the new
|
||||
redirects: Dict[PluginDesc, PluginDesc] = {},
|
||||
redirects: Redirects = {},
|
||||
append: List[PluginDesc] = [],
|
||||
):
|
||||
plugins = load_plugins_from_csv(config, input_file,)
|
||||
@ -618,9 +623,10 @@ def rewrite_input(
|
||||
cur_date_iso = datetime.now().strftime("%Y-%m-%d")
|
||||
with open(deprecated, "r") as f:
|
||||
deprecations = json.load(f)
|
||||
for old, new in redirects.items():
|
||||
old_plugin, _ = prefetch_plugin(old)
|
||||
new_plugin, _ = prefetch_plugin(new)
|
||||
for pdesc, new_repo in redirects.items():
|
||||
new_pdesc = PluginDesc(new_repo, pdesc.branch, pdesc.alias)
|
||||
old_plugin, _ = prefetch_plugin(pdesc)
|
||||
new_plugin, _ = prefetch_plugin(new_pdesc)
|
||||
if old_plugin.normalized_name != new_plugin.normalized_name:
|
||||
deprecations[old_plugin.normalized_name] = {
|
||||
"new": new_plugin.normalized_name,
|
||||
|
||||
@ -31,7 +31,7 @@ from pluginupdate import Editor, update_plugins, FetchConfig, CleanEnvironment
|
||||
PKG_LIST="maintainers/scripts/luarocks-packages.csv"
|
||||
TMP_FILE="$(mktemp)"
|
||||
GENERATED_NIXFILE="pkgs/development/lua-modules/generated-packages.nix"
|
||||
LUAROCKS_CONFIG="$NIXPKGS_PATH/maintainers/scripts/luarocks-config.lua"
|
||||
LUAROCKS_CONFIG="maintainers/scripts/luarocks-config.lua"
|
||||
|
||||
HEADER = """/* {GENERATED_NIXFILE} is an auto-generated file -- DO NOT EDIT!
|
||||
Regenerate it with:
|
||||
@ -158,14 +158,14 @@ def generate_pkg_nix(plug: LuaPlugin):
|
||||
Our cache key associates "p.name-p.version" to its rockspec
|
||||
'''
|
||||
log.debug("Generating nix expression for %s", plug.name)
|
||||
cmd = [ "luarocks", "nix"]
|
||||
custom_env = os.environ.copy()
|
||||
custom_env['LUAROCKS_CONFIG'] = LUAROCKS_CONFIG
|
||||
|
||||
cmd = [ "luarocks", "nix"]
|
||||
|
||||
if plug.maintainers:
|
||||
cmd.append(f"--maintainers={plug.maintainers}")
|
||||
|
||||
# updates plugin directly from its repository
|
||||
print("server: [%s]" % plug.server)
|
||||
# if plug.server == "src":
|
||||
if plug.src != "":
|
||||
if plug.src is None:
|
||||
@ -194,7 +194,8 @@ def generate_pkg_nix(plug: LuaPlugin):
|
||||
cmd.append(f"--lua-dir={lua_drv_path}/bin")
|
||||
|
||||
log.debug("running %s", ' '.join(cmd))
|
||||
output = subprocess.check_output(cmd, text=True)
|
||||
|
||||
output = subprocess.check_output(cmd, env=custom_env, text=True)
|
||||
output = "callPackage(" + output.strip() + ") {};\n\n"
|
||||
return (plug, output)
|
||||
|
||||
|
||||
@ -19,7 +19,10 @@
|
||||
|
||||
More fields may be added in the future.
|
||||
|
||||
Please keep the list alphabetically sorted.
|
||||
When editing this file:
|
||||
* keep the list alphabetically sorted
|
||||
* test the validity of the format with:
|
||||
nix-build lib/tests/teams.nix
|
||||
*/
|
||||
|
||||
{ lib }:
|
||||
@ -91,6 +94,16 @@ with lib.maintainers; {
|
||||
enableFeatureFreezePing = true;
|
||||
};
|
||||
|
||||
c3d2 = {
|
||||
members = [
|
||||
astro
|
||||
SuperSandro2000
|
||||
];
|
||||
scope = "Maintain packages used in the C3D2 hackspace";
|
||||
shortName = "c3d2";
|
||||
enableFeatureFreezePing = true;
|
||||
};
|
||||
|
||||
cinnamon = {
|
||||
members = [
|
||||
mkg20001
|
||||
@ -139,6 +152,7 @@ with lib.maintainers; {
|
||||
tomberek
|
||||
];
|
||||
scope = "Maintain the Cosmopolitan LibC and related programs.";
|
||||
shortName = "Cosmopolitan";
|
||||
};
|
||||
|
||||
deshaw = {
|
||||
@ -198,6 +212,18 @@ with lib.maintainers; {
|
||||
enableFeatureFreezePing = true;
|
||||
};
|
||||
|
||||
enlightenment = {
|
||||
members = [
|
||||
romildo
|
||||
];
|
||||
githubTeams = [
|
||||
"enlightenment"
|
||||
];
|
||||
scope = "Maintain Enlightenment desktop environment and related packages.";
|
||||
shortName = "Enlightenment";
|
||||
enableFeatureFreezePing = true;
|
||||
};
|
||||
|
||||
# Dummy group for the "everyone else" section
|
||||
feature-freeze-everyone-else = {
|
||||
members = [ ];
|
||||
@ -299,7 +325,6 @@ with lib.maintainers; {
|
||||
jitsi = {
|
||||
members = [
|
||||
cleeyv
|
||||
petabyteboy
|
||||
ryantm
|
||||
yuka
|
||||
];
|
||||
@ -343,6 +368,40 @@ with lib.maintainers; {
|
||||
shortName = "Linux Kernel";
|
||||
};
|
||||
|
||||
lumiguide = {
|
||||
# Verify additions by approval of an already existing member of the team.
|
||||
members = [
|
||||
roelvandijk
|
||||
lucus16
|
||||
];
|
||||
scope = "Group registration for LumiGuide employees who collectively maintain packages.";
|
||||
shortName = "Lumiguide employees";
|
||||
};
|
||||
|
||||
lumina = {
|
||||
members = [
|
||||
romildo
|
||||
];
|
||||
githubTeams = [
|
||||
"lumina"
|
||||
];
|
||||
scope = "Maintain lumina desktop environment and related packages.";
|
||||
shortName = "Lumina";
|
||||
enableFeatureFreezePing = true;
|
||||
};
|
||||
|
||||
lxqt = {
|
||||
members = [
|
||||
romildo
|
||||
];
|
||||
githubTeams = [
|
||||
"lxqt"
|
||||
];
|
||||
scope = "Maintain LXQt desktop environment and related packages.";
|
||||
shortName = "LXQt";
|
||||
enableFeatureFreezePing = true;
|
||||
};
|
||||
|
||||
marketing = {
|
||||
members = [
|
||||
garbas
|
||||
@ -409,6 +468,19 @@ with lib.maintainers; {
|
||||
enableFeatureFreezePing = true;
|
||||
};
|
||||
|
||||
numtide = {
|
||||
members = [
|
||||
mic92
|
||||
flokli
|
||||
jfroche
|
||||
tazjin
|
||||
zimbatm
|
||||
];
|
||||
enableFeatureFreezePing = true;
|
||||
scope = "Group registration for Numtide team members who collectively maintain packages.";
|
||||
shortName = "Numtide team";
|
||||
};
|
||||
|
||||
openstack = {
|
||||
members = [
|
||||
emilytrau
|
||||
|
||||
@ -40,7 +40,7 @@ section for details on container networking.)
|
||||
To disable the container, just remove it from `configuration.nix` and
|
||||
run `nixos-rebuild
|
||||
switch`. Note that this will not delete the root directory of the
|
||||
container in `/var/lib/containers`. Containers can be destroyed using
|
||||
container in `/var/lib/nixos-containers`. Containers can be destroyed using
|
||||
the imperative method: `nixos-container destroy foo`.
|
||||
|
||||
Declarative containers can be started and stopped using the
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user