Compare commits
1
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
b6799ab037 |
@@ -24,8 +24,3 @@ indent_size = 4
|
||||
# Match diffs, avoid to trim trailing whitespace
|
||||
[*.{diff,patch}]
|
||||
trim_trailing_whitespace = false
|
||||
|
||||
[*.md]
|
||||
indent_style = space
|
||||
indent_size = 2
|
||||
max_line_length = 0
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
# Pull requests concerning the listed files will automatically invite the respective maintainers as reviewers.
|
||||
# This file is not used for denoting any kind of ownership, but is merely a tool for handling notifications.
|
||||
#
|
||||
# Merge permissions are required for maintaining an entry in this file.
|
||||
# For documentation on this mechanism, see https://help.github.com/articles/about-codeowners/
|
||||
|
||||
# Default reviewers if nothing else matches
|
||||
* @edolstra
|
||||
|
||||
# This file
|
||||
.github/CODEOWNERS @edolstra
|
||||
|
||||
# Public documentation
|
||||
/doc @fricklerhandwerk
|
||||
*.md @fricklerhandwerk
|
||||
|
||||
# Libstore layer
|
||||
/src/libstore @thufschmitt
|
||||
@@ -9,7 +9,7 @@ assignees: ''
|
||||
|
||||
## Platform
|
||||
|
||||
<!-- select the platform on which you tried to install Lix -->
|
||||
<!-- select the platform on which you tried to install Nix -->
|
||||
|
||||
- [ ] Linux: <!-- state your distribution, e.g. Arch Linux, Ubuntu, ... -->
|
||||
- [ ] macOS
|
||||
|
||||
@@ -19,10 +19,9 @@ assignees: ''
|
||||
|
||||
<!-- make sure this issue is not redundant or obsolete -->
|
||||
|
||||
- [ ] checked [latest Lix manual] \([source]\)
|
||||
- [ ] checked [documentation issues] and [recent documentation changes] for possible duplicates
|
||||
- [ ] checked [latest Nix manual] \([source])
|
||||
- [ ] checked [open documentation issues and pull requests] for possible duplicates
|
||||
|
||||
[latest Nix manual]: https://docs.lix.systems/manual/lix/nightly
|
||||
[source]: https://git.lix.systems/lix-project/lix/src/main/doc/manual/src
|
||||
[documentation issues]: https://git.lix.systems/lix-project/lix/issues?labels=151&state=all
|
||||
[recent documentation changes]: https://gerrit.lix.systems/q/p:lix+path:%22%5Edoc/manual/.*%22
|
||||
[latest Nix manual]: https://nixos.org/manual/nix/unstable/
|
||||
[source]: https://github.com/NixOS/nix/tree/master/doc/manual/src
|
||||
[open documentation issues and pull requests]: https://github.com/NixOS/nix/labels/documentation
|
||||
|
||||
@@ -0,0 +1,35 @@
|
||||
# Stale bot information
|
||||
|
||||
- Thanks for your contribution!
|
||||
- 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/) or on [Matrix - #nix:nixos.org](https://matrix.to/#/#nix:nixos.org).
|
||||
|
||||
## Suggestions for PRs
|
||||
|
||||
1. GitHub sometimes doesn't notify people who commented / reviewed a PR previously, when you (force) push commits. If you have addressed the reviews you can [officially ask for a review](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/requesting-a-pull-request-review) from those who commented to you or anyone else.
|
||||
2. If it is unfinished but you plan to finish it, please mark it as a draft.
|
||||
3. If you don't expect to work on it any time soon, closing it with a short comment may encourage someone else to pick up your work.
|
||||
4. To get things rolling again, rebase the PR against the target branch and address valid comments.
|
||||
5. If you need a review to move forward, ask in [the Discourse thread for PRs that need help](https://discourse.nixos.org/t/prs-in-distress/3604).
|
||||
6. If all you need is a merge, check the git history to find and [request reviews](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/requesting-a-pull-request-review) from people who usually merge related contributions.
|
||||
|
||||
## Suggestions for issues
|
||||
|
||||
1. If it is resolved (either for you personally, or in general), please consider closing it.
|
||||
2. If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
|
||||
3. If you still have interest in resolving it, try to ping somebody who you believe might have an interest in the topic. Consider discussing the problem in [our Discourse Forum](https://discourse.nixos.org/).
|
||||
4. As with all open source projects, your best option is to submit a Pull Request that addresses this issue. We :heart: this attitude!
|
||||
|
||||
**Memorandum on closing issues**
|
||||
|
||||
Don't be afraid to close an issue that holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.
|
||||
|
||||
## Useful GitHub search queries
|
||||
|
||||
- [Open PRs with any stale-bot interaction](https://github.com/NixOS/nix/pulls?q=is%3Apr+is%3Aopen+commenter%3Aapp%2Fstale+)
|
||||
- [Open PRs with any stale-bot interaction and `stale`](https://github.com/NixOS/nix/pulls?q=is%3Apr+is%3Aopen+commenter%3Aapp%2Fstale+label%3A%22stale%22)
|
||||
- [Open PRs with any stale-bot interaction and NOT `stale`](https://github.com/NixOS/nix/pulls?q=is%3Apr+is%3Aopen+commenter%3Aapp%2Fstale+-label%3A%22stale%22+)
|
||||
- [Open Issues with any stale-bot interaction](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+commenter%3Aapp%2Fstale+)
|
||||
- [Open Issues with any stale-bot interaction and `stale`](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+commenter%3Aapp%2Fstale+label%3A%22stale%22+)
|
||||
- [Open Issues with any stale-bot interaction and NOT `stale`](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+commenter%3Aapp%2Fstale+-label%3A%22stale%22+)
|
||||
@@ -0,0 +1,6 @@
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "github-actions"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "weekly"
|
||||
@@ -0,0 +1,23 @@
|
||||
"documentation":
|
||||
- doc/manual/*
|
||||
- src/nix/**/*.md
|
||||
|
||||
"store":
|
||||
- src/libstore/store-api.*
|
||||
- src/libstore/*-store.*
|
||||
|
||||
"fetching":
|
||||
- src/libfetchers/**/*
|
||||
|
||||
"repl":
|
||||
- src/libcmd/repl.*
|
||||
- src/nix/repl.*
|
||||
|
||||
"new-cli":
|
||||
- src/nix/**/*
|
||||
|
||||
"with-tests":
|
||||
# Unit tests
|
||||
- src/*/tests/**/*
|
||||
# Functional and integration tests
|
||||
- tests/functional/**/*
|
||||
@@ -0,0 +1,9 @@
|
||||
# Configuration for probot-stale - https://github.com/probot/stale
|
||||
daysUntilStale: 180
|
||||
daysUntilClose: false
|
||||
exemptLabels:
|
||||
- "critical"
|
||||
- "never-stale"
|
||||
staleLabel: "stale"
|
||||
markComment: false
|
||||
closeComment: false
|
||||
+129
-1
@@ -1,5 +1,128 @@
|
||||
Makefile.config
|
||||
perl/Makefile.config
|
||||
|
||||
# /
|
||||
/aclocal.m4
|
||||
/autom4te.cache
|
||||
/precompiled-headers.h.gch
|
||||
/config.*
|
||||
/configure
|
||||
/stamp-h1
|
||||
/svn-revision
|
||||
/libtool
|
||||
/config
|
||||
|
||||
# /doc/manual/
|
||||
/doc/manual/*.1
|
||||
/doc/manual/*.5
|
||||
/doc/manual/*.8
|
||||
/doc/manual/generated/*
|
||||
/doc/manual/nix.json
|
||||
/doc/manual/conf-file.json
|
||||
/doc/manual/language.json
|
||||
/doc/manual/xp-features.json
|
||||
/doc/manual/src/command-ref/experimental-features-shortlist.md
|
||||
/doc/manual/src/contributing/experimental-feature-descriptions.md
|
||||
/doc/manual/src/release-notes/rl-next-generated.md
|
||||
|
||||
# /scripts/
|
||||
/scripts/nix-profile.sh
|
||||
/scripts/nix-profile-daemon.sh
|
||||
/scripts/nix-profile.fish
|
||||
/scripts/nix-profile-daemon.fish
|
||||
|
||||
# /src/libexpr/
|
||||
/src/libexpr/lexer-tab.cc
|
||||
/src/libexpr/lexer-tab.hh
|
||||
/src/libexpr/parser-tab.cc
|
||||
/src/libexpr/parser-tab.hh
|
||||
/src/libexpr/parser-tab.output
|
||||
/src/libexpr/nix.tbl
|
||||
/src/libexpr/tests
|
||||
/tests/unit/libexpr/libnixexpr-tests
|
||||
|
||||
# /src/libstore/
|
||||
*.gen.*
|
||||
/src/libstore/tests
|
||||
/tests/unit/libstore/libnixstore-tests
|
||||
|
||||
# /src/libutil/
|
||||
/src/libutil/tests
|
||||
/tests/unit/libutil/libnixutil-tests
|
||||
|
||||
/src/nix/nix
|
||||
|
||||
/src/nix/doc
|
||||
|
||||
# /src/nix-env/
|
||||
/src/nix-env/nix-env
|
||||
|
||||
# /src/nix-instantiate/
|
||||
/src/nix-instantiate/nix-instantiate
|
||||
|
||||
# /src/nix-store/
|
||||
/src/nix-store/nix-store
|
||||
|
||||
/src/nix-prefetch-url/nix-prefetch-url
|
||||
|
||||
/src/nix-collect-garbage/nix-collect-garbage
|
||||
|
||||
# /src/nix-channel/
|
||||
/src/nix-channel/nix-channel
|
||||
|
||||
# /src/nix-build/
|
||||
/src/nix-build/nix-build
|
||||
|
||||
/src/nix-copy-closure/nix-copy-closure
|
||||
|
||||
/src/error-demo/error-demo
|
||||
|
||||
/src/build-remote/build-remote
|
||||
|
||||
# /tests/functional/
|
||||
/tests/functional/test-tmp
|
||||
/tests/functional/common/vars-and-functions.sh
|
||||
/tests/functional/result*
|
||||
/tests/functional/restricted-innocent
|
||||
/tests/functional/shell
|
||||
/tests/functional/shell.drv
|
||||
/tests/functional/config.nix
|
||||
/tests/functional/ca/config.nix
|
||||
/tests/functional/dyn-drv/config.nix
|
||||
/tests/functional/repl-result-out
|
||||
/tests/functional/debugger-test-out
|
||||
/tests/functional/test-libstoreconsumer/test-libstoreconsumer
|
||||
|
||||
# /tests/functional/lang/
|
||||
/tests/functional/lang/*.out
|
||||
/tests/functional/lang/*.out.xml
|
||||
/tests/functional/lang/*.err
|
||||
/tests/functional/lang/*.ast
|
||||
|
||||
/perl/lib/Nix/Config.pm
|
||||
/perl/lib/Nix/Store.cc
|
||||
|
||||
/misc/systemd/nix-daemon.service
|
||||
/misc/systemd/nix-daemon.socket
|
||||
/misc/systemd/nix-daemon.conf
|
||||
/misc/upstart/nix-daemon.conf
|
||||
|
||||
/src/resolve-system-dependencies/resolve-system-dependencies
|
||||
|
||||
outputs/
|
||||
|
||||
*.a
|
||||
*.o
|
||||
*.o.tmp
|
||||
*.so
|
||||
*.dylib
|
||||
*.dll
|
||||
*.exe
|
||||
*.dep
|
||||
*~
|
||||
*.pc
|
||||
*.plist
|
||||
|
||||
# GNU Global
|
||||
GPATH
|
||||
GRTAGS
|
||||
@@ -9,11 +132,17 @@ GTAGS
|
||||
# ccls
|
||||
/.ccls-cache
|
||||
|
||||
# auto-generated compilation database
|
||||
compile_commands.json
|
||||
|
||||
nix-rust/target
|
||||
|
||||
result
|
||||
result-*
|
||||
|
||||
.vscode/
|
||||
.direnv/
|
||||
.envrc.local
|
||||
|
||||
# clangd and possibly more
|
||||
.cache/
|
||||
@@ -28,4 +157,3 @@ buildtime.bin
|
||||
# We generate this with a Nix shell hook
|
||||
/.pre-commit-config.yaml
|
||||
/.nocontribmsg
|
||||
/release
|
||||
|
||||
+58
-35
@@ -1,53 +1,76 @@
|
||||
# Contributing to Lix
|
||||
# Contributing to Nix
|
||||
|
||||
Welcome and thank you for considering contributing to Lix! We're currently in a soft release phase, and your support means a lot to us.
|
||||
Welcome and thank you for your interest in contributing to Nix!
|
||||
We appreciate your support.
|
||||
|
||||
To ensure a smooth and effective contribution process, here is a summary of our guidelines:
|
||||
|
||||
## Getting help?
|
||||
|
||||
If you have any question regarding getting started or reporting bugs, feel free
|
||||
to reach out to us.
|
||||
|
||||
On Matrix, we have a space at `#space:lix.systems`, composed of:
|
||||
|
||||
- [`#discuss:lix.systems`](https://matrix.to/#/#discuss:lix.systems) for discussions on Lix.
|
||||
- [`#dev:lix.systems`](https://matrix.to/#/#dev:lix.systems) for the development channel on Lix.
|
||||
Reading and following these guidelines will help us make the contribution process easy and effective for everyone involved.
|
||||
|
||||
## Report a bug
|
||||
|
||||
- Check if your bug has already been reported in the [issue tracker](https://git.lix.systems/lix-project/lix/issues).
|
||||
- If you can't find the bug or feature, please open a new issue.
|
||||
1. Check on the [GitHub issue tracker](https://github.com/NixOS/nix/issues) if your bug was already reported.
|
||||
|
||||
We maintain a copy of the upstream Nix bugs. Their organisation can be read about [here](https://wiki.lix.systems/books/lix-contributors/page/bug-tracker-organisation).
|
||||
2. If you were not able to find the bug or feature [open a new issue](https://github.com/NixOS/nix/issues/new/choose)
|
||||
|
||||
3. The issue templates will guide you in specifying your issue.
|
||||
The more complete the information you provide, the more likely it can be found by others and the more useful it is in the future.
|
||||
Make sure reported bugs can be reproduced easily.
|
||||
|
||||
4. Once submitted, do not expect issues to be picked up or solved right away.
|
||||
The only way to ensure this, is to [work on the issue yourself](#making-changes-to-nix).
|
||||
|
||||
## Report a security vulnerability
|
||||
|
||||
For security vulnerabilities, reach out by email at `security at lix dot systems`.
|
||||
Check out the [security policy](https://github.com/NixOS/nix/security/policy).
|
||||
|
||||
## Making changes to Lix
|
||||
## Making changes to Nix
|
||||
|
||||
Before diving into making changes, we want to engage with you and your ideas.
|
||||
1. Check for [pull requests](https://github.com/NixOS/nix/pulls) that might already cover the contribution you are about to make.
|
||||
There are many open pull requests that might already do what you intent to work on.
|
||||
You can use [labels](https://github.com/NixOS/nix/labels) to filter for relevant topics.
|
||||
|
||||
We have a few policies in effect; please take the time to familiarize yourself:
|
||||
2. Search for related issues that cover what you're going to work on. It could help to mention there that you will work on the issue.
|
||||
|
||||
- [Style guide on code](https://wiki.lix.systems/books/lix-contributors/page/code)
|
||||
- [Freeze policy and recommended contributions](https://wiki.lix.systems/books/lix-contributors/page/freezes-and-recommended-contributions)
|
||||
Issues labeled [good first issue](https://github.com/NixOS/nix/labels/good-first-issue) should be relatively easy to fix and are likely to get merged quickly.
|
||||
Pull requests addressing issues labeled [idea approved](https://github.com/NixOS/nix/labels/idea%20approved) are especially welcomed by maintainers and will receive prioritised review.
|
||||
|
||||
To avoid duplication of effort, it may be a good idea to check out the list of
|
||||
[pending pull requests](https://gerrit.lix.systems/q/status:open+-is:wip) (or "change lists", as Gerrit calls them). Once you have
|
||||
an idea of what you might want to do, we recommend dropping a message on our
|
||||
Matrix to ensure your contribution fits with our current schedule and plans
|
||||
3. Check the [Nix reference manual](https://nixos.org/manual/nix/unstable/contributing/hacking.html) for information on building Nix and running its tests.
|
||||
|
||||
When you're ready and your changes are ready to go:
|
||||
For contributions to the command line interface, please check the [CLI guidelines](https://nixos.org/manual/nix/unstable/contributing/cli-guideline.html).
|
||||
|
||||
- Submit your code.
|
||||
- Submitting a GitHub PR [on our mirror](https://github.com/lix-project/lix) is totally ok if that's easier for you and your change is relatively small (300 lines or so).
|
||||
4. Make your changes!
|
||||
|
||||
We may ask you to resubmit it as a Gerrit CL if it is necessary for the change you're making.
|
||||
- Our primary code review system is [our Gerrit instance](https://gerrit.lix.systems), where you can open a change list (CL).
|
||||
If you're new to Gerrit, check out [our wiki page about Gerrit](https://wiki.lix.systems/books/lix-contributors/page/gerrit).
|
||||
- Make sure to link any related issues.
|
||||
- If needed, indicate that the change is 'work in progress'.
|
||||
5. [Create a pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request) for your changes.
|
||||
* Link related issues in your pull request to inform interested parties and future contributors about your change.
|
||||
* Make sure to have [a clean history of commits on your branch by using rebase](https://www.digitalocean.com/community/tutorials/how-to-rebase-and-update-a-pull-request).
|
||||
If your pull request closes one or multiple issues, note that in the description using `Closes: #<number>`, as it will then happen automatically when your change is merged.
|
||||
* [Mark the pull request as draft](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request) if you're not done with the changes.
|
||||
|
||||
You can obtain an account on our platforms by clicking "Sign In with GitHub" on the sign-in page.
|
||||
6. Do not expect your pull request to be reviewed immediately.
|
||||
Nix maintainers follow a [structured process for reviews and design decisions](https://github.com/NixOS/nix/tree/master/maintainers#project-board-protocol), which may or may not prioritise your work.
|
||||
|
||||
Following this checklist will make the process smoother for everyone:
|
||||
|
||||
- [ ] Fixes an [idea approved](https://github.com/NixOS/nix/labels/idea%20approved) issue
|
||||
- [ ] Tests, as appropriate:
|
||||
- Functional tests – [`tests/functional/**.sh`](./tests/functional)
|
||||
- Unit tests – [`src/*/tests`](./src/)
|
||||
- Integration tests – [`tests/nixos/*`](./tests/nixos)
|
||||
- [ ] User documentation in the [manual](..doc/manual/src)
|
||||
- [ ] API documentation in header files
|
||||
- [ ] Code and comments are self-explanatory
|
||||
- [ ] Commit message explains **why** the change was made
|
||||
- [ ] New feature or incompatible change: updated [release notes](./doc/manual/src/release-notes/rl-next.md)
|
||||
|
||||
7. If you need additional feedback or help to getting pull request into shape, ask other contributors using [@mentions](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#mentioning-people-and-teams).
|
||||
|
||||
## Making changes to the Nix manual
|
||||
|
||||
The Nix reference manual is hosted on https://nixos.org/manual/nix.
|
||||
The underlying source files are located in [`doc/manual/src`](./doc/manual/src).
|
||||
For small changes you can [use GitHub to edit these files](https://docs.github.com/en/repositories/working-with-files/managing-files/editing-files)
|
||||
For larger changes see the [Nix reference manual](https://nixos.org/manual/nix/unstable/contributing/hacking.html).
|
||||
|
||||
## Getting help
|
||||
|
||||
Whenever you're stuck or do not know how to proceed, you can always ask for help.
|
||||
The appropriate channels to do so can be found on the [NixOS Community](https://nixos.org/community/) page.
|
||||
|
||||
@@ -0,0 +1,71 @@
|
||||
include mk/build-dir.mk
|
||||
|
||||
-include $(buildprefix)Makefile.config
|
||||
clean-files += $(buildprefix)Makefile.config
|
||||
|
||||
ifeq ($(ENABLE_BUILD), yes)
|
||||
makefiles = \
|
||||
mk/precompiled-headers.mk \
|
||||
local.mk \
|
||||
src/libutil/local.mk \
|
||||
src/libstore/local.mk \
|
||||
src/libfetchers/local.mk \
|
||||
src/libmain/local.mk \
|
||||
src/libexpr/local.mk \
|
||||
src/libcmd/local.mk \
|
||||
src/nix/local.mk \
|
||||
src/resolve-system-dependencies/local.mk \
|
||||
scripts/local.mk \
|
||||
misc/bash/local.mk \
|
||||
misc/fish/local.mk \
|
||||
misc/zsh/local.mk \
|
||||
misc/systemd/local.mk \
|
||||
misc/launchd/local.mk
|
||||
endif
|
||||
|
||||
ifeq ($(ENABLE_BUILD)_$(ENABLE_TESTS), yes_yes)
|
||||
UNIT_TEST_ENV = _NIX_TEST_UNIT_DATA=unit-test-data
|
||||
makefiles += \
|
||||
tests/unit/libutil/local.mk \
|
||||
tests/unit/libutil-support/local.mk \
|
||||
tests/unit/libstore/local.mk
|
||||
endif
|
||||
|
||||
ifeq ($(ENABLE_TESTS), yes)
|
||||
makefiles += \
|
||||
tests/unit/libstore-support/local.mk \
|
||||
tests/unit/libexpr/local.mk \
|
||||
tests/unit/libexpr-support/local.mk \
|
||||
tests/functional/local.mk \
|
||||
tests/functional/ca/local.mk \
|
||||
tests/functional/dyn-drv/local.mk \
|
||||
tests/functional/test-libstoreconsumer/local.mk \
|
||||
tests/functional/repl_characterization/local.mk \
|
||||
tests/functional/plugins/local.mk
|
||||
else
|
||||
makefiles += \
|
||||
mk/disable-tests.mk
|
||||
endif
|
||||
|
||||
# Some makefiles require access to built programs and must be included late.
|
||||
makefiles-late =
|
||||
|
||||
ifeq ($(ENABLE_BUILD), yes)
|
||||
makefiles-late += doc/manual/local.mk
|
||||
makefiles-late += doc/internal-api/local.mk
|
||||
endif
|
||||
|
||||
# Miscellaneous global Flags
|
||||
|
||||
OPTIMIZE = 1
|
||||
|
||||
ifeq ($(OPTIMIZE), 1)
|
||||
GLOBAL_CXXFLAGS += -O2 $(CXXLTO)
|
||||
GLOBAL_LDFLAGS += $(CXXLTO)
|
||||
else
|
||||
GLOBAL_CXXFLAGS += -O0 -U_FORTIFY_SOURCE
|
||||
endif
|
||||
|
||||
include mk/lib.mk
|
||||
|
||||
GLOBAL_CXXFLAGS += -g -Wall -Wimplicit-fallthrough -include $(buildprefix)config.h -std=c++2a -I src
|
||||
@@ -0,0 +1,52 @@
|
||||
AR = @AR@
|
||||
BDW_GC_LIBS = @BDW_GC_LIBS@
|
||||
BOOST_LDFLAGS = @BOOST_LDFLAGS@
|
||||
BUILD_SHARED_LIBS = @BUILD_SHARED_LIBS@
|
||||
CC = @CC@
|
||||
CFLAGS = @CFLAGS@
|
||||
CXX = @CXX@
|
||||
CXXFLAGS = @CXXFLAGS@
|
||||
CXXLTO = @CXXLTO@
|
||||
EDITLINE_LIBS = @EDITLINE_LIBS@
|
||||
ENABLE_S3 = @ENABLE_S3@
|
||||
GTEST_LIBS = @GTEST_LIBS@
|
||||
HAVE_LIBCPUID = @HAVE_LIBCPUID@
|
||||
HAVE_SECCOMP = @HAVE_SECCOMP@
|
||||
HOST_OS = @host_os@
|
||||
LDFLAGS = @LDFLAGS@
|
||||
LIBARCHIVE_LIBS = @LIBARCHIVE_LIBS@
|
||||
LIBBROTLI_LIBS = @LIBBROTLI_LIBS@
|
||||
LIBCURL_LIBS = @LIBCURL_LIBS@
|
||||
LIBSECCOMP_LIBS = @LIBSECCOMP_LIBS@
|
||||
LOWDOWN_LIBS = @LOWDOWN_LIBS@
|
||||
NIXDOC_LIBS = -llix_doc
|
||||
OPENSSL_LIBS = @OPENSSL_LIBS@
|
||||
PACKAGE_NAME = @PACKAGE_NAME@
|
||||
PACKAGE_VERSION = @PACKAGE_VERSION@
|
||||
RAPIDCHECK_HEADERS = @RAPIDCHECK_HEADERS@
|
||||
SHELL = @bash@
|
||||
SODIUM_LIBS = @SODIUM_LIBS@
|
||||
SQLITE3_LIBS = @SQLITE3_LIBS@
|
||||
bash = @bash@
|
||||
bindir = @bindir@
|
||||
datadir = @datadir@
|
||||
datarootdir = @datarootdir@
|
||||
doc_generate = @doc_generate@
|
||||
docdir = @docdir@
|
||||
embedded_sandbox_shell = @embedded_sandbox_shell@
|
||||
exec_prefix = @exec_prefix@
|
||||
includedir = @includedir@
|
||||
libdir = @libdir@
|
||||
libexecdir = @libexecdir@
|
||||
localstatedir = @localstatedir@
|
||||
lsof = @lsof@
|
||||
mandir = @mandir@
|
||||
pkglibdir = $(libdir)/$(PACKAGE_NAME)
|
||||
prefix = @prefix@
|
||||
sandbox_shell = @sandbox_shell@
|
||||
storedir = @storedir@
|
||||
sysconfdir = @sysconfdir@
|
||||
system = @system@
|
||||
ENABLE_BUILD = @ENABLE_BUILD@
|
||||
ENABLE_TESTS = @ENABLE_TESTS@
|
||||
internal_api_docs = @internal_api_docs@
|
||||
@@ -6,14 +6,14 @@ Read more about us at https://lix.systems.
|
||||
|
||||
## Installation
|
||||
|
||||
On Linux and macOS the easiest way to install Lix is to run the following shell command
|
||||
On Linux and macOS the easiest way to install Nix is to run the following shell command
|
||||
(as a user other than root):
|
||||
|
||||
```console
|
||||
$ curl -sSf -L https://install.lix.systems/lix | sh -s -- install
|
||||
```
|
||||
|
||||
For systems that **already have a Nix implementation installed**, such as NixOS systems, read our [install page](https://lix.systems/install)
|
||||
For systems that **already have Nix installed**, such as NixOS systems, read our [install page](https://lix.systems/install)
|
||||
|
||||
## Building And Developing
|
||||
|
||||
@@ -22,7 +22,7 @@ See our [Hacking guide](https://git.lix.systems/lix-project/lix/src/branch/main/
|
||||
## Additional Resources
|
||||
|
||||
- [Our wiki](https://wiki.lix.systems)
|
||||
- [Matrix - #space:lix.systems](https://matrix.to/#/#space:lix.systems)
|
||||
- [Matrix - #nix:nixos.org](https://matrix.to/#/#space:lix.systems)
|
||||
|
||||
## License
|
||||
|
||||
|
||||
@@ -1,8 +1,56 @@
|
||||
diff --git a/darwin_stop_world.c b/darwin_stop_world.c
|
||||
index 0468aaec..b348d869 100644
|
||||
--- a/darwin_stop_world.c
|
||||
+++ b/darwin_stop_world.c
|
||||
@@ -356,6 +356,7 @@ GC_INNER void GC_push_all_stacks(void)
|
||||
int nthreads = 0;
|
||||
word total_size = 0;
|
||||
mach_msg_type_number_t listcount = (mach_msg_type_number_t)THREAD_TABLE_SZ;
|
||||
+ size_t stack_limit;
|
||||
if (!EXPECT(GC_thr_initialized, TRUE))
|
||||
GC_thr_init();
|
||||
|
||||
@@ -411,6 +412,19 @@ GC_INNER void GC_push_all_stacks(void)
|
||||
GC_push_all_stack_sections(lo, hi, p->traced_stack_sect);
|
||||
}
|
||||
if (altstack_lo) {
|
||||
+ // When a thread goes into a coroutine, we lose its original sp until
|
||||
+ // control flow returns to the thread.
|
||||
+ // While in the coroutine, the sp points outside the thread stack,
|
||||
+ // so we can detect this and push the entire thread stack instead,
|
||||
+ // as an approximation.
|
||||
+ // We assume that the coroutine has similarly added its entire stack.
|
||||
+ // This could be made accurate by cooperating with the application
|
||||
+ // via new functions and/or callbacks.
|
||||
+ stack_limit = pthread_get_stacksize_np(p->id);
|
||||
+ if (altstack_lo >= altstack_hi || altstack_lo < altstack_hi - stack_limit) { // sp outside stack
|
||||
+ altstack_lo = altstack_hi - stack_limit;
|
||||
+ }
|
||||
+
|
||||
total_size += altstack_hi - altstack_lo;
|
||||
GC_push_all_stack(altstack_lo, altstack_hi);
|
||||
}
|
||||
diff --git a/include/gc.h b/include/gc.h
|
||||
index edab6c22..f2c61282 100644
|
||||
--- a/include/gc.h
|
||||
+++ b/include/gc.h
|
||||
@@ -2172,6 +2172,11 @@ GC_API void GC_CALL GC_win32_free_heap(void);
|
||||
(*GC_amiga_allocwrapper_do)(a,GC_malloc_atomic_ignore_off_page)
|
||||
#endif /* _AMIGA && !GC_AMIGA_MAKINGLIB */
|
||||
|
||||
+#if !__APPLE__
|
||||
+/* Patch doesn't work on apple */
|
||||
+#define NIX_BOEHM_PATCH_VERSION 1
|
||||
+#endif
|
||||
+
|
||||
#ifdef __cplusplus
|
||||
} /* extern "C" */
|
||||
#endif
|
||||
diff --git a/pthread_stop_world.c b/pthread_stop_world.c
|
||||
index 2b45489..0e6d8ef 100644
|
||||
index b5d71e62..aed7b0bf 100644
|
||||
--- a/pthread_stop_world.c
|
||||
+++ b/pthread_stop_world.c
|
||||
@@ -776,6 +776,8 @@ STATIC void GC_restart_handler(int sig)
|
||||
@@ -768,6 +768,8 @@ STATIC void GC_restart_handler(int sig)
|
||||
/* world is stopped. Should not fail if it isn't. */
|
||||
GC_INNER void GC_push_all_stacks(void)
|
||||
{
|
||||
@@ -11,23 +59,20 @@ index 2b45489..0e6d8ef 100644
|
||||
GC_bool found_me = FALSE;
|
||||
size_t nthreads = 0;
|
||||
int i;
|
||||
@@ -868,6 +870,40 @@ GC_INNER void GC_push_all_stacks(void)
|
||||
hi = p->altstack + p->altstack_size;
|
||||
# endif
|
||||
@@ -851,6 +853,37 @@ GC_INNER void GC_push_all_stacks(void)
|
||||
hi = p->altstack + p->altstack_size;
|
||||
/* FIXME: Need to scan the normal stack too, but how ? */
|
||||
/* FIXME: Assume stack grows down */
|
||||
+ } else {
|
||||
+ #ifdef HAVE_PTHREAD_ATTR_GET_NP
|
||||
+ if (pthread_attr_init(&pattr) != 0) {
|
||||
+ ABORT("GC_push_all_stacks: pthread_attr_init failed!");
|
||||
+ }
|
||||
+ if (pthread_attr_get_np(p->id, &pattr) != 0) {
|
||||
+ ABORT("GC_push_all_stacks: pthread_attr_get_np failed!");
|
||||
+ }
|
||||
+ #else
|
||||
+ if (pthread_getattr_np(p->id, &pattr)) {
|
||||
+#ifdef HAVE_PTHREAD_ATTR_GET_NP
|
||||
+ if (!pthread_attr_init(&pattr)
|
||||
+ || !pthread_attr_get_np(p->id, &pattr))
|
||||
+#else /* HAVE_PTHREAD_GETATTR_NP */
|
||||
+ if (pthread_getattr_np(p->id, &pattr))
|
||||
+#endif
|
||||
+ {
|
||||
+ ABORT("GC_push_all_stacks: pthread_getattr_np failed!");
|
||||
+ }
|
||||
+ #endif
|
||||
+ if (pthread_attr_getstacksize(&pattr, &stack_limit)) {
|
||||
+ ABORT("GC_push_all_stacks: pthread_attr_getstacksize failed!");
|
||||
+ }
|
||||
@@ -50,5 +95,5 @@ index 2b45489..0e6d8ef 100644
|
||||
+ #error "STACK_GROWS_UP not supported in boost_coroutine2 (as of june 2021), so we don't support it in Nix."
|
||||
+ #endif
|
||||
}
|
||||
# ifdef STACKPTR_CORRECTOR_AVAILABLE
|
||||
if (GC_sp_corrector != 0)
|
||||
GC_push_all_stack_sections(lo, hi, traced_stack_sect);
|
||||
# ifdef STACK_GROWS_UP
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
diff --git a/include/gc_allocator.h b/include/gc_allocator.h
|
||||
index 597c7f13..587286be 100644
|
||||
--- a/include/gc_allocator.h
|
||||
+++ b/include/gc_allocator.h
|
||||
@@ -312,6 +312,7 @@ public:
|
||||
|
||||
template<>
|
||||
class traceable_allocator<void> {
|
||||
+public:
|
||||
typedef size_t size_type;
|
||||
typedef ptrdiff_t difference_type;
|
||||
typedef void* pointer;
|
||||
+17
-26
@@ -44,41 +44,32 @@ void FixIncludesCallbacks::LexedFileChanged(FileID, LexedFileChangeReason,
|
||||
}
|
||||
|
||||
void FixIncludesCallbacks::InclusionDirective(
|
||||
SourceLocation, const Token &, StringRef FileName, bool IsAngled,
|
||||
SourceLocation, const Token &, StringRef, bool,
|
||||
CharSourceRange FilenameRange, OptionalFileEntryRef File, StringRef,
|
||||
StringRef, const Module *, SrcMgr::CharacteristicKind) {
|
||||
if (Ignore)
|
||||
return;
|
||||
|
||||
// FIXME: this is kinda evil, but this is a one-time fixup
|
||||
const std::vector<std::string> SourceDirs = {"src/", "include/lix/"};
|
||||
const std::string SourceDir = "src/";
|
||||
|
||||
const auto Bracketize = [IsAngled](StringRef s) {
|
||||
return IsAngled ? ("<" + s + ">").str() : ("\"" + s + "\"").str();
|
||||
};
|
||||
if (File && File->getNameAsRequested().contains(SourceDir)) {
|
||||
StringRef Name = File->getNameAsRequested();
|
||||
auto Idx = Name.find(SourceDir);
|
||||
assert(Idx != std::string::npos);
|
||||
StringRef Suffix = Name.drop_front(Idx + SourceDir.length());
|
||||
|
||||
for (const auto &SourceDir : SourceDirs) {
|
||||
const bool IsAlreadyFixed = FileName.starts_with("lix/lib");
|
||||
if (File && File->getNameAsRequested().contains(SourceDir) &&
|
||||
!IsAlreadyFixed) {
|
||||
StringRef Name = File->getNameAsRequested();
|
||||
auto Idx = Name.find(SourceDir);
|
||||
assert(Idx != std::string::npos);
|
||||
std::string Suffix = Name.drop_front(Idx + SourceDir.length()).str();
|
||||
|
||||
if (!Suffix.starts_with("lib")) {
|
||||
llvm::dbgs() << "ignored: " << Suffix << "\n";
|
||||
return;
|
||||
}
|
||||
|
||||
Suffix = "lix/" + Suffix;
|
||||
|
||||
auto Diag = Check.diag(FilenameRange.getBegin(),
|
||||
"include needs to specify the source subdir");
|
||||
|
||||
Diag << FilenameRange
|
||||
<< FixItHint::CreateReplacement(FilenameRange, Bracketize(Suffix));
|
||||
if (!Suffix.starts_with("lib")) {
|
||||
llvm::dbgs() << "ignored: " << Suffix << "\n";
|
||||
return;
|
||||
}
|
||||
|
||||
auto Diag = Check.diag(FilenameRange.getBegin(),
|
||||
"include needs to specify the source subdir");
|
||||
|
||||
Diag << FilenameRange
|
||||
<< FixItHint::CreateReplacement(FilenameRange,
|
||||
("\"" + Suffix + "\"").str());
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Clang tidy lints for Lix
|
||||
# Clang tidy lints for Nix
|
||||
|
||||
This is a skeleton of a clang-tidy lints library for Lix.
|
||||
This is a skeleton of a clang-tidy lints library for Nix.
|
||||
|
||||
Currently there is one check (which is already obsolete as it has served its
|
||||
goal and is there as an example), `HasPrefixSuffixCheck`.
|
||||
@@ -10,13 +10,13 @@ goal and is there as an example), `HasPrefixSuffixCheck`.
|
||||
One file:
|
||||
|
||||
```
|
||||
ninja -C build && clang-tidy --checks='-*,lix-*' --load=build/liblix-clang-tidy.so -p ../compile_commands.json -header-filter '\.\./src/.*\.h' --fix ../src/libcmd/installables.cc
|
||||
ninja -C build && clang-tidy --checks='-*,nix-*' --load=build/libnix-clang-tidy.so -p ../compile_commands.json --fix ../src/libcmd/installables.cc
|
||||
```
|
||||
|
||||
Several files, in parallel:
|
||||
|
||||
```
|
||||
ninja -C build && run-clang-tidy -checks='-*,lix-*' -load=build/liblix-clang-tidy.so -p .. -header-filter '\.\./src/.*\.h' -fix ../src | tee -a clang-tidy-result
|
||||
ninja -C build && run-clang-tidy -checks='-*,nix-*' -load=build/libnix-clang-tidy.so -p .. -fix ../src | tee -a clang-tidy-result
|
||||
```
|
||||
|
||||
## Resources
|
||||
|
||||
+396
@@ -0,0 +1,396 @@
|
||||
AC_INIT([nix],[m4_esyscmd(bash -c "echo -n $(cat ./.version)$VERSION_SUFFIX")])
|
||||
AC_CONFIG_MACRO_DIRS([m4])
|
||||
AC_CONFIG_SRCDIR(README.md)
|
||||
AC_CONFIG_AUX_DIR(config)
|
||||
|
||||
AC_PROG_SED
|
||||
|
||||
# Construct a Nix system name (like "i686-linux"):
|
||||
# https://www.gnu.org/software/autoconf/manual/html_node/Canonicalizing.html#index-AC_005fCANONICAL_005fHOST-1
|
||||
# The inital value is produced by the `config/config.guess` script:
|
||||
# upstream: https://git.savannah.gnu.org/cgit/config.git/tree/config.guess
|
||||
# It has the following form, which is not documented anywhere:
|
||||
# <cpu>-<vendor>-<os>[<version>][-<abi>]
|
||||
# If `./configure` is passed any of the `--host`, `--build`, `--target` options, the value comes from `config/config.sub` instead:
|
||||
# upstream: https://git.savannah.gnu.org/cgit/config.git/tree/config.sub
|
||||
AC_CANONICAL_HOST
|
||||
AC_MSG_CHECKING([for the canonical Nix system name])
|
||||
|
||||
AC_ARG_WITH(system, AS_HELP_STRING([--with-system=SYSTEM],[Platform identifier (e.g., `i686-linux').]),
|
||||
[system=$withval],
|
||||
[case "$host_cpu" in
|
||||
i*86)
|
||||
machine_name="i686";;
|
||||
amd64)
|
||||
machine_name="x86_64";;
|
||||
armv6|armv7)
|
||||
machine_name="${host_cpu}l";;
|
||||
*)
|
||||
machine_name="$host_cpu";;
|
||||
esac
|
||||
|
||||
case "$host_os" in
|
||||
linux-gnu*|linux-musl*)
|
||||
# For backward compatibility, strip the `-gnu' part.
|
||||
system="$machine_name-linux";;
|
||||
*)
|
||||
# Strip the version number from names such as `gnu0.3',
|
||||
# `darwin10.2.0', etc.
|
||||
system="$machine_name-`echo $host_os | "$SED" -e's/@<:@0-9.@:>@*$//g'`";;
|
||||
esac])
|
||||
|
||||
AC_MSG_RESULT($system)
|
||||
AC_SUBST(system)
|
||||
AC_DEFINE_UNQUOTED(SYSTEM, ["$system"], [platform identifier ('cpu-os')])
|
||||
|
||||
|
||||
# State should be stored in /nix/var, unless the user overrides it explicitly.
|
||||
test "$localstatedir" = '${prefix}/var' && localstatedir=/nix/var
|
||||
|
||||
# Assign a default value to C{,XX}FLAGS as the default configure script sets them
|
||||
# to -O2 otherwise, which we don't want to have hardcoded
|
||||
CFLAGS=${CFLAGS-""}
|
||||
CXXFLAGS=${CXXFLAGS-""}
|
||||
|
||||
AC_PROG_CC
|
||||
AC_PROG_CXX
|
||||
AC_PROG_CPP
|
||||
|
||||
AC_CHECK_TOOL([AR], [ar])
|
||||
|
||||
# Use 64-bit file system calls so that we can support files > 2 GiB.
|
||||
AC_SYS_LARGEFILE
|
||||
|
||||
|
||||
# Solaris-specific stuff.
|
||||
AC_STRUCT_DIRENT_D_TYPE
|
||||
case "$host_os" in
|
||||
solaris*)
|
||||
# Solaris requires -lsocket -lnsl for network functions
|
||||
LDFLAGS="-lsocket -lnsl $LDFLAGS"
|
||||
;;
|
||||
esac
|
||||
|
||||
|
||||
ENSURE_NO_GCC_BUG_80431
|
||||
|
||||
|
||||
# Check for pubsetbuf.
|
||||
AC_MSG_CHECKING([for pubsetbuf])
|
||||
AC_LANG_PUSH(C++)
|
||||
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <iostream>
|
||||
using namespace std;
|
||||
static char buf[1024];]],
|
||||
[[cerr.rdbuf()->pubsetbuf(buf, sizeof(buf));]])],
|
||||
[AC_MSG_RESULT(yes) AC_DEFINE(HAVE_PUBSETBUF, 1, [Whether pubsetbuf is available.])],
|
||||
AC_MSG_RESULT(no))
|
||||
AC_LANG_POP(C++)
|
||||
|
||||
|
||||
AC_CHECK_FUNCS([statvfs pipe2])
|
||||
|
||||
|
||||
# Check for lutimes, optionally used for changing the mtime of
|
||||
# symlinks.
|
||||
AC_CHECK_FUNCS([lutimes])
|
||||
|
||||
|
||||
# Check whether the store optimiser can optimise symlinks.
|
||||
AC_MSG_CHECKING([whether it is possible to create a link to a symlink])
|
||||
ln -s bla tmp_link
|
||||
if ln tmp_link tmp_link2 2> /dev/null; then
|
||||
AC_MSG_RESULT(yes)
|
||||
AC_DEFINE(CAN_LINK_SYMLINK, 1, [Whether link() works on symlinks.])
|
||||
else
|
||||
AC_MSG_RESULT(no)
|
||||
fi
|
||||
rm -f tmp_link tmp_link2
|
||||
|
||||
|
||||
# Check for <locale>.
|
||||
AC_LANG_PUSH(C++)
|
||||
AC_CHECK_HEADERS([locale])
|
||||
AC_LANG_POP(C++)
|
||||
|
||||
|
||||
AC_DEFUN([NEED_PROG],
|
||||
[
|
||||
AC_PATH_PROG($1, $2)
|
||||
if test -z "$$1"; then
|
||||
AC_MSG_ERROR([$2 is required])
|
||||
fi
|
||||
])
|
||||
|
||||
NEED_PROG(bash, bash)
|
||||
AC_PATH_PROG(flex, flex, false)
|
||||
AC_PATH_PROG(bison, bison, false)
|
||||
AC_PATH_PROG(dot, dot)
|
||||
AC_PATH_PROG(lsof, lsof, lsof)
|
||||
NEED_PROG(jq, jq)
|
||||
|
||||
|
||||
AC_SUBST(coreutils, [$(dirname $(type -p cat))])
|
||||
|
||||
|
||||
AC_ARG_WITH(store-dir, AS_HELP_STRING([--with-store-dir=PATH],[path of the Nix store (defaults to /nix/store)]),
|
||||
storedir=$withval, storedir='/nix/store')
|
||||
AC_SUBST(storedir)
|
||||
|
||||
|
||||
# Look for boost, a required dependency.
|
||||
# Note that AX_BOOST_BASE only exports *CPP* BOOST_CPPFLAGS, no CXX flags,
|
||||
# and CPPFLAGS are not passed to the C++ compiler automatically.
|
||||
# Thus we append the returned CPPFLAGS to the CXXFLAGS here.
|
||||
AX_BOOST_BASE([1.66], [CXXFLAGS="$BOOST_CPPFLAGS $CXXFLAGS"], [AC_MSG_ERROR([Nix requires boost.])])
|
||||
# For unknown reasons, setting this directly in the ACTION-IF-FOUND above
|
||||
# ends up with LDFLAGS being empty, so we set it afterwards.
|
||||
LDFLAGS="$BOOST_LDFLAGS $LDFLAGS"
|
||||
|
||||
# On some platforms, new-style atomics need a helper library
|
||||
AC_MSG_CHECKING(whether -latomic is needed)
|
||||
AC_LINK_IFELSE([AC_LANG_SOURCE([[
|
||||
#include <stdint.h>
|
||||
uint64_t v;
|
||||
int main() {
|
||||
return (int)__atomic_load_n(&v, __ATOMIC_ACQUIRE);
|
||||
}]])], GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC=no, GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC=yes)
|
||||
AC_MSG_RESULT($GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC)
|
||||
if test "x$GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC" = xyes; then
|
||||
LDFLAGS="-latomic $LDFLAGS"
|
||||
fi
|
||||
|
||||
# Running the functional tests without building Nix is useful for testing
|
||||
# different pre-built versions of Nix against each other.
|
||||
AC_ARG_ENABLE(build, AS_HELP_STRING([--disable-build],[Do not build nix]),
|
||||
ENABLE_BUILD=$enableval, ENABLE_BUILD=yes)
|
||||
AC_SUBST(ENABLE_BUILD)
|
||||
# Building without tests is useful for bootstrapping with a smaller footprint
|
||||
# or running the tests in a separate derivation. Otherwise, we do compile and
|
||||
# run them.
|
||||
AC_ARG_ENABLE(tests, AS_HELP_STRING([--disable-tests],[Do not build the tests]),
|
||||
ENABLE_TESTS=$enableval, ENABLE_TESTS=yes)
|
||||
AC_SUBST(ENABLE_TESTS)
|
||||
|
||||
# Building without API docs is the default as Nix' C++ interfaces are internal and unstable.
|
||||
AC_ARG_ENABLE(internal_api_docs, AS_HELP_STRING([--enable-internal-api-docs],[Build API docs for Nix's internal unstable C++ interfaces]),
|
||||
internal_api_docs=$enableval, internal_api_docs=no)
|
||||
AC_SUBST(internal_api_docs)
|
||||
|
||||
# LTO is currently broken with clang for unknown reasons; ld segfaults in the llvm plugin
|
||||
AC_ARG_ENABLE(lto, AS_HELP_STRING([--enable-lto],[Enable LTO (only supported with GCC) [default=no]]),
|
||||
lto=$enableval, lto=no)
|
||||
if test "$lto" = yes; then
|
||||
if $CXX --version | grep -q GCC; then
|
||||
AC_SUBST(CXXLTO, [-flto=jobserver])
|
||||
else
|
||||
echo "error: LTO is only supported with GCC at the moment" >&2
|
||||
exit 1
|
||||
fi
|
||||
else
|
||||
AC_SUBST(CXXLTO, [""])
|
||||
fi
|
||||
|
||||
PKG_PROG_PKG_CONFIG
|
||||
|
||||
AC_ARG_ENABLE(shared, AS_HELP_STRING([--enable-shared],[Build shared libraries for Nix [default=yes]]),
|
||||
shared=$enableval, shared=yes)
|
||||
if test "$shared" = yes; then
|
||||
AC_SUBST(BUILD_SHARED_LIBS, 1, [Whether to build shared libraries.])
|
||||
else
|
||||
AC_SUBST(BUILD_SHARED_LIBS, 0, [Whether to build shared libraries.])
|
||||
PKG_CONFIG="$PKG_CONFIG --static"
|
||||
fi
|
||||
|
||||
# Look for OpenSSL, a required dependency. FIXME: this is only (maybe)
|
||||
# used by S3BinaryCacheStore.
|
||||
PKG_CHECK_MODULES([OPENSSL], [libcrypto >= 1.1.1], [CXXFLAGS="$OPENSSL_CFLAGS $CXXFLAGS"])
|
||||
|
||||
|
||||
# Look for libarchive.
|
||||
PKG_CHECK_MODULES([LIBARCHIVE], [libarchive >= 3.1.2], [CXXFLAGS="$LIBARCHIVE_CFLAGS $CXXFLAGS"])
|
||||
# Workaround until https://github.com/libarchive/libarchive/issues/1446 is fixed
|
||||
if test "$shared" != yes; then
|
||||
LIBARCHIVE_LIBS+=' -lz'
|
||||
fi
|
||||
|
||||
# Look for SQLite, a required dependency.
|
||||
PKG_CHECK_MODULES([SQLITE3], [sqlite3 >= 3.6.19], [CXXFLAGS="$SQLITE3_CFLAGS $CXXFLAGS"])
|
||||
|
||||
# Look for libcurl, a required dependency.
|
||||
PKG_CHECK_MODULES([LIBCURL], [libcurl], [CXXFLAGS="$LIBCURL_CFLAGS $CXXFLAGS"])
|
||||
|
||||
# Look for editline, a required dependency.
|
||||
# The the libeditline.pc file was added only in libeditline >= 1.15.2,
|
||||
# see https://github.com/troglobit/editline/commit/0a8f2ef4203c3a4a4726b9dd1336869cd0da8607,
|
||||
# but e.g. Ubuntu 16.04 has an older version, so we fall back to searching for
|
||||
# editline.h when the pkg-config approach fails.
|
||||
PKG_CHECK_MODULES([EDITLINE], [libeditline], [CXXFLAGS="$EDITLINE_CFLAGS $CXXFLAGS"], [
|
||||
AC_CHECK_HEADERS([editline.h], [true],
|
||||
[AC_MSG_ERROR([Nix requires libeditline; it was found neither via pkg-config nor its normal header.])])
|
||||
AC_SEARCH_LIBS([readline read_history], [editline], [],
|
||||
[AC_MSG_ERROR([Nix requires libeditline; it was not found via pkg-config, but via its header, but required functions do not work. Maybe it is too old? >= 1.14 is required.])])
|
||||
])
|
||||
|
||||
# Look for libsodium.
|
||||
PKG_CHECK_MODULES([SODIUM], [libsodium], [CXXFLAGS="$SODIUM_CFLAGS $CXXFLAGS"])
|
||||
|
||||
# Look for libbrotli{enc,dec}.
|
||||
PKG_CHECK_MODULES([LIBBROTLI], [libbrotlienc libbrotlidec], [CXXFLAGS="$LIBBROTLI_CFLAGS $CXXFLAGS"])
|
||||
|
||||
# Look for libcpuid.
|
||||
have_libcpuid=
|
||||
if test "$machine_name" = "x86_64"; then
|
||||
AC_ARG_ENABLE([cpuid],
|
||||
AS_HELP_STRING([--disable-cpuid], [Do not determine microarchitecture levels with libcpuid (relevant to x86_64 only)]))
|
||||
if test "x$enable_cpuid" != "xno"; then
|
||||
PKG_CHECK_MODULES([LIBCPUID], [libcpuid],
|
||||
[CXXFLAGS="$LIBCPUID_CFLAGS $CXXFLAGS"
|
||||
have_libcpuid=1
|
||||
AC_DEFINE([HAVE_LIBCPUID], [1], [Use libcpuid])]
|
||||
)
|
||||
fi
|
||||
fi
|
||||
AC_SUBST(HAVE_LIBCPUID, [$have_libcpuid])
|
||||
|
||||
|
||||
# Look for libseccomp, required for Linux sandboxing.
|
||||
case "$host_os" in
|
||||
linux*)
|
||||
AC_ARG_ENABLE([seccomp-sandboxing],
|
||||
AS_HELP_STRING([--disable-seccomp-sandboxing],[Don't build support for seccomp sandboxing (only recommended if your arch doesn't support libseccomp yet!)
|
||||
]))
|
||||
if test "x$enable_seccomp_sandboxing" != "xno"; then
|
||||
PKG_CHECK_MODULES([LIBSECCOMP], [libseccomp],
|
||||
[CXXFLAGS="$LIBSECCOMP_CFLAGS $CXXFLAGS"])
|
||||
have_seccomp=1
|
||||
AC_DEFINE([HAVE_SECCOMP], [1], [Whether seccomp is available and should be used for sandboxing.])
|
||||
else
|
||||
have_seccomp=
|
||||
fi
|
||||
;;
|
||||
*)
|
||||
have_seccomp=
|
||||
;;
|
||||
esac
|
||||
AC_SUBST(HAVE_SECCOMP, [$have_seccomp])
|
||||
|
||||
|
||||
# Look for aws-cpp-sdk-s3.
|
||||
AC_LANG_PUSH(C++)
|
||||
AC_CHECK_HEADERS([aws/s3/S3Client.h],
|
||||
[AC_DEFINE([ENABLE_S3], [1], [Whether to enable S3 support via aws-sdk-cpp.]) enable_s3=1],
|
||||
[AC_DEFINE([ENABLE_S3], [0], [Whether to enable S3 support via aws-sdk-cpp.]) enable_s3=])
|
||||
AC_SUBST(ENABLE_S3, [$enable_s3])
|
||||
AC_LANG_POP(C++)
|
||||
|
||||
if test -n "$enable_s3"; then
|
||||
declare -a aws_version_tokens=($(printf '#include <aws/core/VersionConfig.h>\nAWS_SDK_VERSION_STRING' | $CPP $CPPFLAGS - | grep -v '^#.*' | sed 's/"//g' | tr '.' ' '))
|
||||
AC_DEFINE_UNQUOTED([AWS_VERSION_MAJOR], ${aws_version_tokens@<:@0@:>@}, [Major version of aws-sdk-cpp.])
|
||||
AC_DEFINE_UNQUOTED([AWS_VERSION_MINOR], ${aws_version_tokens@<:@1@:>@}, [Minor version of aws-sdk-cpp.])
|
||||
AC_DEFINE_UNQUOTED([AWS_VERSION_PATCH], ${aws_version_tokens@<:@2@:>@}, [Patch version of aws-sdk-cpp.])
|
||||
fi
|
||||
|
||||
|
||||
# Whether to use the Boehm garbage collector.
|
||||
AC_ARG_ENABLE(gc, AS_HELP_STRING([--enable-gc],[enable garbage collection in the Nix expression evaluator (requires Boehm GC) [default=yes]]),
|
||||
gc=$enableval, gc=yes)
|
||||
if test "$gc" = yes; then
|
||||
PKG_CHECK_MODULES([BDW_GC], [bdw-gc])
|
||||
CXXFLAGS="$BDW_GC_CFLAGS $CXXFLAGS"
|
||||
AC_DEFINE(HAVE_BOEHMGC, 1, [Whether to use the Boehm garbage collector.])
|
||||
fi
|
||||
|
||||
|
||||
if test "$ENABLE_TESTS" = yes; then
|
||||
|
||||
# Look for gtest.
|
||||
PKG_CHECK_MODULES([GTEST], [gtest_main gmock_main])
|
||||
|
||||
|
||||
# Look for rapidcheck.
|
||||
AC_ARG_VAR([RAPIDCHECK_HEADERS], [include path of gtest headers shipped by RAPIDCHECK])
|
||||
# No pkg-config yet, https://github.com/emil-e/rapidcheck/issues/302
|
||||
AC_LANG_PUSH(C++)
|
||||
AC_SUBST(RAPIDCHECK_HEADERS)
|
||||
[CXXFLAGS="-I $RAPIDCHECK_HEADERS $CXXFLAGS"]
|
||||
[LIBS="-lrapidcheck -lgtest $LIBS"]
|
||||
AC_CHECK_HEADERS([rapidcheck/gtest.h], [], [], [#include <gtest/gtest.h>])
|
||||
dnl AC_CHECK_LIB doesn't work for C++ libs with mangled symbols
|
||||
AC_LINK_IFELSE([
|
||||
AC_LANG_PROGRAM([[
|
||||
#include <gtest/gtest.h>
|
||||
#include <rapidcheck/gtest.h>
|
||||
]], [[
|
||||
return RUN_ALL_TESTS();
|
||||
]])
|
||||
],
|
||||
[],
|
||||
[AC_MSG_ERROR([librapidcheck is not found.])])
|
||||
AC_LANG_POP(C++)
|
||||
|
||||
fi
|
||||
|
||||
# Look for nlohmann/json.
|
||||
PKG_CHECK_MODULES([NLOHMANN_JSON], [nlohmann_json >= 3.9])
|
||||
|
||||
|
||||
# documentation generation switch
|
||||
AC_ARG_ENABLE(doc-gen, AS_HELP_STRING([--disable-doc-gen],[disable documentation generation]),
|
||||
doc_generate=$enableval, doc_generate=yes)
|
||||
AC_SUBST(doc_generate)
|
||||
|
||||
# Look for lowdown library.
|
||||
PKG_CHECK_MODULES([LOWDOWN], [lowdown >= 0.9.0], [CXXFLAGS="$LOWDOWN_CFLAGS $CXXFLAGS"])
|
||||
|
||||
# Look for toml11, a required dependency.
|
||||
AC_ARG_VAR([TOML11_HEADERS], [include path of toml11 headers])
|
||||
AC_LANG_PUSH(C++)
|
||||
[CXXFLAGS="-I $TOML11_HEADERS $CXXFLAGS"]
|
||||
AC_CHECK_HEADER([toml.hpp], [], [AC_MSG_ERROR([toml11 is not found.])])
|
||||
AC_LANG_POP(C++)
|
||||
|
||||
# Setuid installations.
|
||||
AC_CHECK_FUNCS([setresuid setreuid lchown])
|
||||
|
||||
|
||||
# Nice to have, but not essential.
|
||||
AC_CHECK_FUNCS([strsignal posix_fallocate sysconf])
|
||||
|
||||
|
||||
AC_ARG_WITH(sandbox-shell, AS_HELP_STRING([--with-sandbox-shell=PATH],[path of a statically-linked shell to use as /bin/sh in sandboxes]),
|
||||
sandbox_shell=$withval)
|
||||
AC_SUBST(sandbox_shell)
|
||||
if test ${cross_compiling:-no} = no && ! test -z ${sandbox_shell+x}; then
|
||||
AC_MSG_CHECKING([whether sandbox-shell has the standalone feature])
|
||||
# busybox shell sometimes allows executing other busybox applets,
|
||||
# even if they are not in the path, breaking our sandbox
|
||||
if PATH= $sandbox_shell -c "busybox" 2>&1 | grep -qv "not found"; then
|
||||
AC_MSG_RESULT(enabled)
|
||||
AC_MSG_ERROR([Please disable busybox FEATURE_SH_STANDALONE])
|
||||
else
|
||||
AC_MSG_RESULT(disabled)
|
||||
fi
|
||||
fi
|
||||
|
||||
AC_ARG_ENABLE(embedded-sandbox-shell, AS_HELP_STRING([--enable-embedded-sandbox-shell],[include the sandbox shell in the Nix binary [default=no]]),
|
||||
embedded_sandbox_shell=$enableval, embedded_sandbox_shell=no)
|
||||
AC_SUBST(embedded_sandbox_shell)
|
||||
if test "$embedded_sandbox_shell" = yes; then
|
||||
AC_DEFINE(HAVE_EMBEDDED_SANDBOX_SHELL, 1, [Include the sandbox shell in the Nix binary.])
|
||||
fi
|
||||
|
||||
|
||||
# Expand all variables in config.status.
|
||||
test "$prefix" = NONE && prefix=$ac_default_prefix
|
||||
test "$exec_prefix" = NONE && exec_prefix='${prefix}'
|
||||
for name in $ac_subst_vars; do
|
||||
declare $name="$(eval echo "${!name}")"
|
||||
declare $name="$(eval echo "${!name}")"
|
||||
declare $name="$(eval echo "${!name}")"
|
||||
done
|
||||
|
||||
rm -f Makefile.config
|
||||
|
||||
AC_CONFIG_HEADERS([config.h])
|
||||
AC_CONFIG_FILES([])
|
||||
AC_OUTPUT
|
||||
@@ -0,0 +1,19 @@
|
||||
.PHONY: internal-api-html
|
||||
|
||||
ifeq ($(internal_api_docs), yes)
|
||||
|
||||
$(docdir)/internal-api/html/index.html $(docdir)/internal-api/latex: $(d)/doxygen.cfg
|
||||
mkdir -p $(docdir)/internal-api
|
||||
{ cat $< ; echo "OUTPUT_DIRECTORY=$(docdir)/internal-api" ; } | doxygen -
|
||||
|
||||
# Generate the HTML API docs for Nix's unstable internal interfaces.
|
||||
internal-api-html: $(docdir)/internal-api/html/index.html
|
||||
|
||||
else
|
||||
|
||||
# Make a nicer error message
|
||||
internal-api-html:
|
||||
@echo "Internal API docs are disabled. Configure with '--enable-internal-api-docs', or avoid calling 'make internal-api-html'."
|
||||
@exit 1
|
||||
|
||||
endif
|
||||
@@ -28,7 +28,6 @@ internal_api_docs = custom_target(
|
||||
output : 'html',
|
||||
install : true,
|
||||
install_dir : datadir / 'doc/nix/internal-api',
|
||||
build_always_stale : true,
|
||||
)
|
||||
|
||||
alias_target('internal-api-html', internal_api_docs)
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
[book]
|
||||
title = "Lix Reference Manual"
|
||||
title = "Nix Reference Manual"
|
||||
|
||||
[build]
|
||||
create-missing = false
|
||||
@@ -7,14 +7,8 @@ create-missing = false
|
||||
[output.html]
|
||||
additional-css = ["custom.css"]
|
||||
additional-js = ["redirects.js"]
|
||||
# Using our GitHub mirror enables easier typo fixes since there is no easy way
|
||||
# to just submit a Gerrit CL by the web for trivial stuff.
|
||||
edit-url-template = "https://github.com/lix-project/lix/tree/main/doc/manual/{path}"
|
||||
git-repository-url = "https://git.lix.systems/lix-project/lix"
|
||||
# Folding by default would prevent things like "Ctrl+F for nix-env" from working
|
||||
# trivially, but the user should be able to fold if they want to.
|
||||
fold.enable = true
|
||||
fold.level = 30
|
||||
edit-url-template = "https://github.com/NixOS/nix/tree/master/doc/manual/{path}"
|
||||
git-repository-url = "https://github.com/NixOS/nix"
|
||||
|
||||
# Handles replacing @docroot@ with a path to ./src relative to that markdown file,
|
||||
# {{#include handlebars}}, and the @generated@ syntax used within these. it mostly
|
||||
|
||||
@@ -1,115 +0,0 @@
|
||||
# This file is a mapping of metadata for change authors, sort of like
|
||||
# maintainer-list.nix in nixpkgs.
|
||||
#
|
||||
# It's used for crediting people accurately in release notes. The release notes
|
||||
# script will link to forgejo, then to GitHub if forgejo is not present.
|
||||
9999years:
|
||||
display_name: wiggles
|
||||
forgejo: rbt
|
||||
github: 9999years
|
||||
|
||||
Artturin:
|
||||
github: Artturin
|
||||
|
||||
DavHau:
|
||||
github: DavHau
|
||||
|
||||
Kha:
|
||||
github: Kha
|
||||
|
||||
Lunaphied:
|
||||
forgejo: Lunaphied
|
||||
github: Lunaphied
|
||||
|
||||
Qyriad:
|
||||
forgejo: Qyriad
|
||||
github: Qyriad
|
||||
|
||||
SharzyL:
|
||||
github: SharzyL
|
||||
|
||||
alois31:
|
||||
forgejo: alois31
|
||||
github: alois31
|
||||
|
||||
artemist:
|
||||
display_name: Artemis Tosini
|
||||
forgejo: artemist
|
||||
|
||||
cole-h:
|
||||
display_name: Cole Helbling
|
||||
github: cole-h
|
||||
|
||||
edolstra:
|
||||
display_name: Eelco Dolstra
|
||||
github: edolstra
|
||||
|
||||
ericson:
|
||||
display_name: John Ericson
|
||||
github: ericson2314
|
||||
|
||||
horrors:
|
||||
display_name: eldritch horrors
|
||||
forgejo: pennae
|
||||
github: pennae
|
||||
|
||||
iFreilicht:
|
||||
github: iFreilicht
|
||||
|
||||
jade:
|
||||
forgejo: jade
|
||||
github: lf-
|
||||
|
||||
lovesegfault:
|
||||
github: lovesegfault
|
||||
|
||||
ma27:
|
||||
forgejo: ma27
|
||||
github: ma27
|
||||
|
||||
matthewbauer:
|
||||
github: matthewbauer
|
||||
|
||||
midnightveil:
|
||||
display_name: julia
|
||||
forgejo: midnightveil
|
||||
github: midnightveil
|
||||
|
||||
ncfavier:
|
||||
github: ncfavier
|
||||
|
||||
puck:
|
||||
display_name: puck
|
||||
forgejo: puck
|
||||
github: puckipedia
|
||||
|
||||
r-vdp:
|
||||
github: r-vdp
|
||||
|
||||
raito:
|
||||
display_name: Raito Bezarius
|
||||
forgejo: raito
|
||||
github: RaitoBezarius
|
||||
|
||||
roberth:
|
||||
display_name: Robert Hensing
|
||||
github: roberth
|
||||
|
||||
thufschmitt:
|
||||
display_name: Théophane Hufschmitt
|
||||
github: thufschmitt
|
||||
|
||||
tomberek:
|
||||
display_name: Tom Bereknyei
|
||||
github: tomberek
|
||||
|
||||
valentin:
|
||||
display_name: Valentin Gagarin
|
||||
github: fricklerhandwerk
|
||||
|
||||
winter:
|
||||
forgejo: winter
|
||||
github: winterqt
|
||||
|
||||
yshui:
|
||||
github: yshui
|
||||
@@ -0,0 +1,178 @@
|
||||
ifeq ($(doc_generate),yes)
|
||||
|
||||
# The version of Nix used to generate the doc. Can also be
|
||||
# `$(nix_INSTALL_PATH)` or just `nix` (to grap ambient from the `PATH`),
|
||||
# if one prefers.
|
||||
doc_nix = $(nix_PATH)
|
||||
|
||||
MANUAL_SRCS := \
|
||||
$(call rwildcard, $(d)/src, *.md) \
|
||||
$(call rwildcard, $(d)/src, */*.md)
|
||||
|
||||
man-pages := $(foreach n, \
|
||||
nix-env.1 nix-store.1 \
|
||||
nix-build.1 nix-shell.1 nix-instantiate.1 \
|
||||
nix-collect-garbage.1 \
|
||||
nix-prefetch-url.1 nix-channel.1 \
|
||||
nix-hash.1 nix-copy-closure.1 \
|
||||
nix.conf.5 nix-daemon.8 \
|
||||
nix-profiles.5 \
|
||||
, doc/manual/generated/in/$(n))
|
||||
|
||||
# man pages for subcommands
|
||||
# convert from `$(d)/src/command-ref/nix-{1}/{2}.md` to `$(d)/nix-{1}-{2}.1`
|
||||
# FIXME: unify with how nix3-cli man pages are generated
|
||||
man-pages += $(foreach subcommand, \
|
||||
$(filter-out %opt-common.md %env-common.md, $(wildcard $(d)/src/command-ref/nix-*/*.md)), \
|
||||
doc/manual/generated/in/$(subst /,-,$(subst $(d)/src/command-ref/,,$(subst .md,.1,$(subcommand)))))
|
||||
|
||||
clean-files += $(d)/*.1 $(d)/*.5 $(d)/*.8
|
||||
|
||||
# Provide a dummy environment for nix, so that it will not access files outside the macOS sandbox.
|
||||
# Set cores to 0 because otherwise nix config show resolves the cores based on the current machine
|
||||
dummy-env = env -i \
|
||||
HOME=/dummy \
|
||||
NIX_CONF_DIR=/dummy \
|
||||
NIX_SSL_CERT_FILE=/dummy/no-ca-bundle.crt \
|
||||
NIX_STATE_DIR=/dummy \
|
||||
NIX_CONFIG='cores = 0'
|
||||
|
||||
nix-eval = $(dummy-env) $(doc_nix) eval --experimental-features nix-command -I nix/corepkgs=corepkgs --store dummy:// --impure --raw
|
||||
|
||||
doc/manual/generated/in/nix-env-%.1: doc/manual/generated/out
|
||||
$(trace-gen) doc/manual/render-manpage.sh \
|
||||
--out-no-smarty "$(subst nix-env-,nix-env --,$$(basename "$@" .1))" 1 \
|
||||
doc/manual/generated/out/markdown/command-ref/nix-env/$*.md \
|
||||
$@
|
||||
|
||||
doc/manual/generated/in/nix-store-%.1: doc/manual/generated/out
|
||||
$(trace-gen) doc/manual/render-manpage.sh \
|
||||
--out-no-smarty "$(subst nix-store-,nix-store --,$$(basename "$@" .1))" 1 \
|
||||
doc/manual/generated/out/markdown/command-ref/nix-store/$*.md \
|
||||
$@
|
||||
|
||||
|
||||
doc/manual/generated/in/%.1: doc/manual/generated/out
|
||||
$(trace-gen) doc/manual/render-manpage.sh "$$(basename $@ .1)" 1 \
|
||||
doc/manual/generated/out/markdown/command-ref/$*.md \
|
||||
$@
|
||||
|
||||
doc/manual/generated/in/%.8: doc/manual/generated/out
|
||||
$(trace-gen) doc/manual/render-manpage.sh "$$(basename $@ .8)" 8 \
|
||||
doc/manual/generated/out/markdown/command-ref/$*.md \
|
||||
$@
|
||||
|
||||
doc/manual/generated/in/nix.conf.5: doc/manual/generated/out
|
||||
$(trace-gen) doc/manual/render-manpage.sh "$$(basename $@ .5)" 5 \
|
||||
doc/manual/generated/out/markdown/command-ref/conf-file.md \
|
||||
$@
|
||||
|
||||
doc/manual/generated/in/nix-profiles.5: doc/manual/generated/out
|
||||
$(trace-gen) doc/manual/render-manpage.sh "$$(basename $@ .5)" 5 \
|
||||
doc/manual/generated/out/markdown/command-ref/files/profiles.md \
|
||||
$@
|
||||
|
||||
doc/manual/generated/in/command-ref/new-cli: doc/manual/generated/in/nix.json $(d)/utils.nix $(d)/generate-manpage.nix $(doc_nix)
|
||||
@mkdir -p doc/manual/generated/in/command-ref
|
||||
@rm -rf $@ $@.tmp
|
||||
$(trace-gen) $(nix-eval) --write-to $@.tmp --expr 'import doc/manual/generate-manpage.nix true (builtins.readFile $<)'
|
||||
@mv $@.tmp $@
|
||||
|
||||
doc/manual/generated/in/command-ref/conf-file.md: doc/manual/generated/in/conf-file.json $(d)/utils.nix doc/manual/generated/in/command-ref/experimental-features-shortlist.md $(doc_nix)
|
||||
@mkdir -p doc/manual/generated/in/command-ref
|
||||
$(trace-gen) $(nix-eval) --expr '(import doc/manual/utils.nix).showSettings { inlineHTML = true; } (builtins.fromJSON (builtins.readFile $<))' >> $@
|
||||
|
||||
doc/manual/generated/in/nix.json: $(doc_nix)
|
||||
@mkdir -p doc/manual/generated/in
|
||||
$(trace-gen) $(dummy-env) $(doc_nix) __dump-cli > $@.tmp
|
||||
@mv $@.tmp $@
|
||||
|
||||
doc/manual/generated/in/conf-file.json: $(doc_nix)
|
||||
@mkdir -p doc/manual/generated/in
|
||||
$(trace-gen) $(dummy-env) $(doc_nix) config show --json --experimental-features nix-command > $@.tmp
|
||||
@mv $@.tmp $@
|
||||
|
||||
doc/manual/generated/in/contributing/experimental-feature-descriptions.md: doc/manual/generated/in/xp-features.json $(d)/utils.nix $(d)/generate-xp-features.nix $(doc_nix)
|
||||
@mkdir -p doc/manual/generated/in/contributing
|
||||
@rm -rf $@ $@.tmp
|
||||
$(trace-gen) $(nix-eval) --write-to $@.tmp --expr 'import doc/manual/generate-xp-features.nix (builtins.fromJSON (builtins.readFile $<))'
|
||||
@mv $@.tmp $@
|
||||
|
||||
doc/manual/generated/in/command-ref/experimental-features-shortlist.md: doc/manual/generated/in/xp-features.json $(d)/utils.nix $(d)/generate-xp-features-shortlist.nix $(doc_nix)
|
||||
@mkdir -p doc/manual/generated/in/command-ref
|
||||
@rm -rf $@ $@.tmp
|
||||
$(trace-gen) $(nix-eval) --write-to $@.tmp --expr 'import doc/manual/generate-xp-features-shortlist.nix (builtins.fromJSON (builtins.readFile $<))'
|
||||
@mv $@.tmp $@
|
||||
|
||||
doc/manual/generated/in/xp-features.json: $(doc_nix)
|
||||
$(trace-gen) $(dummy-env) NIX_PATH=nix/corepkgs=corepkgs $(doc_nix) __dump-xp-features > $@.tmp
|
||||
@mv $@.tmp $@
|
||||
|
||||
doc/manual/generated/in/language/builtins.md: doc/manual/generated/in/language.json $(d)/generate-builtins.nix $(doc_nix)
|
||||
@mkdir -p doc/manual/generated/in/language
|
||||
$(trace-gen) $(nix-eval) --expr 'import doc/manual/generate-builtins.nix (builtins.fromJSON (builtins.readFile $<)).builtins' >> $@
|
||||
|
||||
doc/manual/generated/in/language/builtin-constants.md: doc/manual/generated/in/language.json $(d)/generate-builtin-constants.nix $(doc_nix)
|
||||
@mkdir -p doc/manual/generated/in/language
|
||||
$(trace-gen) $(nix-eval) --expr 'import doc/manual/generate-builtin-constants.nix (builtins.fromJSON (builtins.readFile $<)).constants' >> $@
|
||||
|
||||
doc/manual/generated/in/language.json: $(doc_nix)
|
||||
@mkdir -p doc/manual/generated/in
|
||||
$(trace-gen) $(dummy-env) NIX_PATH=nix/corepkgs=corepkgs $(doc_nix) __dump-language > $@.tmp
|
||||
@mv $@.tmp $@
|
||||
|
||||
# Generate "Upcoming release" notes (or clear it and remove from menu)
|
||||
doc/manual/generated/in/release-notes/rl-next-generated.md: $(d)/rl-next $(d)/rl-next/*
|
||||
@mkdir -p doc/manual/generated/in/release-notes
|
||||
@if type -p build-release-notes > /dev/null; then \
|
||||
echo " GEN " $@; \
|
||||
build-release-notes doc/manual/rl-next > $@; \
|
||||
else \
|
||||
echo " NULL " $@; \
|
||||
true > $@; \
|
||||
fi
|
||||
|
||||
# Generate the HTML manual.
|
||||
.PHONY: manual-html
|
||||
manual-html: $(docdir)/manual/index.html
|
||||
install: $(docdir)/manual/index.html
|
||||
|
||||
# Generate 'nix' manpages.
|
||||
install: $(mandir)/man1/nix3-manpages
|
||||
man: doc/manual/generated/man1/nix3-manpages
|
||||
all: doc/manual/generated/man1/nix3-manpages
|
||||
|
||||
# FIXME: unify with how the other man pages are generated.
|
||||
# this one works differently and does not use any of the amenities provided by `/mk/lib.mk`.
|
||||
$(mandir)/man1/nix3-manpages: doc/manual/generated/man1/nix3-manpages
|
||||
@mkdir -p $(DESTDIR)$$(dirname $@)
|
||||
$(trace-install) install -m 0644 $$(dirname $<)/* $(DESTDIR)$$(dirname $@)
|
||||
|
||||
doc/manual/generated/man1/nix3-manpages: doc/manual/generated/out
|
||||
@mkdir -p $(DESTDIR)$$(dirname $@)
|
||||
$(trace-gen) for i in doc/manual/generated/out/markdown/command-ref/new-cli/*.md; do \
|
||||
name=$$(basename $$i .md); \
|
||||
tmpFile=$$(mktemp); \
|
||||
if [[ $$name = SUMMARY ]]; then continue; fi; \
|
||||
printf "Title: %s\n\n" "$$name" > $$tmpFile; \
|
||||
cat $$i >> $$tmpFile; \
|
||||
lowdown -sT man --nroff-nolinks -M section=1 $$tmpFile -o $(DESTDIR)$$(dirname $@)/$$name.1; \
|
||||
rm $$tmpFile; \
|
||||
done
|
||||
@touch $@
|
||||
|
||||
doc/manual/generated/out: $(MANUAL_SRCS) $(d)/book.toml $(d)/anchors.jq $(d)/custom.css $(d)/src/SUMMARY.md doc/manual/generated/in/command-ref/new-cli doc/manual/generated/in/command-ref/experimental-features-shortlist.md doc/manual/generated/in/contributing/experimental-feature-descriptions.md doc/manual/generated/in/command-ref/conf-file.md doc/manual/generated/in/language/builtins.md doc/manual/generated/in/language/builtin-constants.md doc/manual/generated/in/release-notes/rl-next-generated.md $(d)/substitute.py
|
||||
@rm -rf $@
|
||||
$(trace-gen) \
|
||||
MDBOOK_SUBSTITUTE_SEARCH=doc/manual/generated/in \
|
||||
RUST_LOG=warn \
|
||||
mdbook build doc/manual -d generated/out 2>&1 \
|
||||
| { grep -Fv "because fragment resolution isn't implemented" || :; }
|
||||
@find $@ -iname meson.build -delete
|
||||
|
||||
$(docdir)/manual/index.html: doc/manual/generated/out
|
||||
@mkdir -p $(DESTDIR)$(docdir)
|
||||
@rm -rf $(DESTDIR)$(docdir)/manual
|
||||
@cp -r $</html $(DESTDIR)$(docdir)/manual
|
||||
|
||||
endif
|
||||
@@ -1,8 +0,0 @@
|
||||
[lix-docs]
|
||||
type = s3
|
||||
provider = Other
|
||||
env_auth = true
|
||||
endpoint = https://s3.lix.systems
|
||||
location_constraint = garage
|
||||
region = garage
|
||||
acl = private
|
||||
@@ -24,6 +24,7 @@ const redirects = {
|
||||
"chap-writing-nix-expressions": "language/index.html",
|
||||
"part-command-ref": "command-ref/command-ref.html",
|
||||
"conf-allow-import-from-derivation": "command-ref/conf-file.html#conf-allow-import-from-derivation",
|
||||
"conf-allow-new-privileges": "command-ref/conf-file.html#conf-allow-new-privileges",
|
||||
"conf-allowed-uris": "command-ref/conf-file.html#conf-allowed-uris",
|
||||
"conf-allowed-users": "command-ref/conf-file.html#conf-allowed-users",
|
||||
"conf-auto-optimise-store": "command-ref/conf-file.html#conf-auto-optimise-store",
|
||||
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
synopsis: Clang build timing analysis
|
||||
cls: 587
|
||||
---
|
||||
|
||||
We now have Clang build profiling available, which generates Chrome
|
||||
tracing files for each compilation unit. To enable it, run `meson configure
|
||||
build -Dprofile-build=enabled` then rerun the compilation.
|
||||
|
||||
If you want to make the build go faster, do a clang build with meson, then run
|
||||
`maintainers/buildtime_report.sh build`, then contemplate how to improve the
|
||||
build time.
|
||||
|
||||
You can also look at individual object files' traces in
|
||||
<https://ui.perfetto.dev>.
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
synopsis: Concise error printing in `nix repl`
|
||||
prs: 9928
|
||||
cls: 811
|
||||
---
|
||||
|
||||
Previously, if an element of a list or attribute set threw an error while
|
||||
evaluating, `nix repl` would print the entire error (including source location
|
||||
information) inline. This output was clumsy and difficult to parse:
|
||||
|
||||
```
|
||||
nix-repl> { err = builtins.throw "uh oh!"; }
|
||||
{ err = «error:
|
||||
… while calling the 'throw' builtin
|
||||
at «string»:1:9:
|
||||
1| { err = builtins.throw "uh oh!"; }
|
||||
| ^
|
||||
|
||||
error: uh oh!»; }
|
||||
```
|
||||
|
||||
Now, only the error message is displayed, making the output much more readable.
|
||||
```
|
||||
nix-repl> { err = builtins.throw "uh oh!"; }
|
||||
{ err = «error: uh oh!»; }
|
||||
```
|
||||
|
||||
However, if the whole expression being evaluated throws an error, source
|
||||
locations and (if applicable) a stack trace are printed, just like you'd expect:
|
||||
|
||||
```
|
||||
nix-repl> builtins.throw "uh oh!"
|
||||
error:
|
||||
… while calling the 'throw' builtin
|
||||
at «string»:1:1:
|
||||
1| builtins.throw "uh oh!"
|
||||
| ^
|
||||
|
||||
error: uh oh!
|
||||
```
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
synopsis: "`--debugger` can now access bindings from `let` expressions"
|
||||
prs: 9918
|
||||
issues: 8827
|
||||
---
|
||||
|
||||
Breakpoints and errors in the bindings of a `let` expression can now access
|
||||
those bindings in the debugger. Previously, only the body of `let` expressions
|
||||
could access those bindings.
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
synopsis: Enter the `--debugger` when `builtins.trace` is called if `debugger-on-trace` is set
|
||||
prs: 9914
|
||||
---
|
||||
|
||||
If the `debugger-on-trace` option is set and `--debugger` is given,
|
||||
`builtins.trace` calls will behave similarly to `builtins.break` and will enter
|
||||
the debug REPL. This is useful for determining where warnings are being emitted
|
||||
from.
|
||||
@@ -0,0 +1,7 @@
|
||||
---
|
||||
synopsis: Stop vendoring toml11
|
||||
cls: 675
|
||||
---
|
||||
|
||||
We don't apply any patches to it, and vendoring it locks users into
|
||||
bugs (it hasn't been updated since its introduction in late 2021).
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
synopsis: Fix handling of truncated `.drv` files.
|
||||
prs: 9673
|
||||
---
|
||||
|
||||
Previously a `.drv` that was truncated in the middle of a string would case nix to enter an infinite loop, eventually exhausting all memory and crashing.
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
synopsis: Duplicate attribute reports are more accurate
|
||||
cls: 557
|
||||
---
|
||||
|
||||
Duplicate attribute errors are now more accurate, showing the path at which an error was detected rather than the full, possibly longer, path that caused the error.
|
||||
Error reports are now
|
||||
```ShellSession
|
||||
$ nix eval --expr '{ a.b = 1; a.b.c.d = 1; }'
|
||||
error: attribute 'a.b' already defined at «string»:1:3
|
||||
at «string»:1:12:
|
||||
1| { a.b = 1; a.b.c.d = 1;
|
||||
| ^
|
||||
```
|
||||
instead of
|
||||
```ShellSession
|
||||
$ nix eval --expr '{ a.b = 1; a.b.c.d = 1; }'
|
||||
error: attribute 'a.b.c.d' already defined at «string»:1:3
|
||||
at «string»:1:12:
|
||||
1| { a.b = 1; a.b.c.d = 1;
|
||||
| ^
|
||||
```
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
synopsis: Disallow empty search regex in `nix search`
|
||||
prs: 9481
|
||||
---
|
||||
|
||||
[`nix search`](@docroot@/command-ref/new-cli/nix3-search.md) now requires a search regex to be passed. To show all packages, use `^`.
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
synopsis: The `--debugger` will start more reliably in `let` expressions and function calls
|
||||
prs: 9917
|
||||
issues: 6649
|
||||
---
|
||||
|
||||
Previously, if you attempted to evaluate this file with the debugger:
|
||||
|
||||
```nix
|
||||
let
|
||||
a = builtins.trace "before inner break" (
|
||||
builtins.break "hello"
|
||||
);
|
||||
b = builtins.trace "before outer break" (
|
||||
builtins.break a
|
||||
);
|
||||
in
|
||||
b
|
||||
```
|
||||
|
||||
Nix would correctly enter the debugger at `builtins.break a`, but if you asked
|
||||
it to `:continue`, it would skip over the `builtins.break "hello"` expression
|
||||
entirely.
|
||||
|
||||
Now, Nix will correctly enter the debugger at both breakpoints.
|
||||
@@ -0,0 +1,7 @@
|
||||
---
|
||||
synopsis: Reduce eval memory usage and wall time
|
||||
prs: 9658
|
||||
---
|
||||
|
||||
Reduce the size of the `Env` struct used in the evaluator by a pointer, or 8 bytes on most modern machines.
|
||||
This reduces memory usage during eval by around 2% and wall time by around 3%.
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
synopsis: Add new `eval-system` setting
|
||||
prs: 4093
|
||||
---
|
||||
|
||||
Add a new `eval-system` option.
|
||||
Unlike `system`, it just overrides the value of `builtins.currentSystem`.
|
||||
This is more useful than overriding `system`, because you can build these derivations on remote builders which can work on the given system.
|
||||
In contrast, `system` also effects scheduling which will cause Nix to build those derivations locally even if that doesn't make sense.
|
||||
|
||||
`eval-system` only takes effect if it is non-empty.
|
||||
If empty (the default) `system` is used as before, so there is no breakage.
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
synopsis: Creating setuid/setgid binaries with fchmodat2 is now prohibited by the build sandbox
|
||||
prs: 10501
|
||||
---
|
||||
|
||||
The build sandbox blocks any attempt to create setuid/setgid binaries, but didn't check
|
||||
for the use of the `fchmodat2` syscall which was introduced in Linux 6.6 and is used by
|
||||
glibc >=2.39. This is fixed now.
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
synopsis: Fix nested flake input `follows`
|
||||
prs: 6621
|
||||
cls: 994
|
||||
---
|
||||
|
||||
Previously nested-input overrides were ignored; that is, the following did not
|
||||
override anything, in spite of the `nix3-flake` manual documenting it working:
|
||||
|
||||
```
|
||||
{
|
||||
inputs = {
|
||||
foo.url = "github:bar/foo";
|
||||
foo.inputs.bar.inputs.nixpkgs = "nixpkgs";
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
This is useful to avoid the 1000 instances of nixpkgs problem without having
|
||||
each flake in the dependency tree to expose all of its transitive dependencies
|
||||
for modification.
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
synopsis: Nested debuggers are no longer supported
|
||||
prs: 9920
|
||||
---
|
||||
|
||||
Previously, evaluating an expression that throws an error in the debugger would
|
||||
enter a second, nested debugger:
|
||||
|
||||
```
|
||||
nix-repl> builtins.throw "what"
|
||||
error: what
|
||||
|
||||
|
||||
Starting REPL to allow you to inspect the current state of the evaluator.
|
||||
|
||||
Welcome to Nix 2.18.1. Type :? for help.
|
||||
|
||||
nix-repl>
|
||||
```
|
||||
|
||||
Now, it just prints the error message like `nix repl`:
|
||||
|
||||
```
|
||||
nix-repl> builtins.throw "what"
|
||||
error:
|
||||
… while calling the 'throw' builtin
|
||||
at «string»:1:1:
|
||||
1| builtins.throw "what"
|
||||
| ^
|
||||
|
||||
error: what
|
||||
```
|
||||
@@ -0,0 +1,7 @@
|
||||
---
|
||||
synopsis: consistent order of lambda formals in printed expressions
|
||||
prs: 9874
|
||||
---
|
||||
|
||||
Always print lambda formals in lexicographic order rather than the internal, creation-time based symbol order.
|
||||
This makes printed formals independent of the context they appear in.
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
synopsis: fix duplicate attribute error positions for `inherit`
|
||||
prs: 9874
|
||||
---
|
||||
|
||||
When an inherit caused a duplicate attribute error the position of the error was not reported correctly, placing the error with the inherit itself or at the start of the bindings block instead of the offending attribute name.
|
||||
@@ -0,0 +1,7 @@
|
||||
---
|
||||
synopsis: "`inherit (x) ...` evaluates `x` only once"
|
||||
prs: 9847
|
||||
---
|
||||
|
||||
`inherit (x) a b ...` now evaluates the expression `x` only once for all inherited attributes rather than once for each inherited attribute.
|
||||
This does not usually have a measurable impact, but side-effects (such as `builtins.trace`) would be duplicated and expensive expressions (such as derivations) could cause a measurable slowdown.
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
synopsis: Store paths are allowed to start with `.`
|
||||
issues: 912
|
||||
prs: [9867, 9091, 9095, 9120, 9121, 9122, 9130, 9219, 9224]
|
||||
---
|
||||
|
||||
Leading periods were allowed by accident in Nix 2.4. The Nix team has considered this to be a bug, but this behavior has since been relied on by users, leading to unnecessary difficulties.
|
||||
From now on, leading periods are officially, definitively supported. The names `.` and `..` are disallowed, as well as those starting with `.-` or `..-`.
|
||||
|
||||
Nix versions that denied leading periods are documented [in the issue](https://github.com/NixOS/nix/issues/912#issuecomment-1919583286).
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
synopsis: Lix turns more internal bugs into crashes
|
||||
cls: [797, 626]
|
||||
---
|
||||
|
||||
Lix now enables build options such as trapping on signed overflow and enabling
|
||||
libstdc++ assertions by default. These may find new bugs in Lix, which will
|
||||
present themselves as Lix processes aborting, potentially without an error
|
||||
message.
|
||||
|
||||
If Lix processes abort on your machine, this is a bug. Please file a bug,
|
||||
ideally with the core dump (or information from it).
|
||||
|
||||
On Linux, run `coredumpctl list`, find the crashed process's PID at
|
||||
the bottom of the list, then run `coredumpctl info THE-PID`. You can then paste
|
||||
the output into a bug report.
|
||||
|
||||
On macOS, open the Console app from Applications/Utilities, select Crash
|
||||
Reports, select the crash report in question. Right click on it, select Open In
|
||||
Finder, then include that file in your bug report. [See the Apple
|
||||
documentation][apple-crashreport] for more details.
|
||||
|
||||
[apple-crashreport]: https://developer.apple.com/documentation/xcode/acquiring-crash-reports-and-diagnostic-logs#Locate-crash-reports-and-memory-logs-on-the-device
|
||||
@@ -0,0 +1,7 @@
|
||||
---
|
||||
synopsis: rename 'nix show-config' to 'nix config show'
|
||||
issues: 7672
|
||||
prs: 9477
|
||||
---
|
||||
|
||||
`nix show-config` was renamed to `nix config show` to be more consistent with the rest of the command-line interface.
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
synopsis: Fix `nix-env --query --drv-path --json`
|
||||
prs: 9257
|
||||
---
|
||||
|
||||
Fixed a bug where `nix-env --query` ignored `--drv-path` when `--json` was set.
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
synopsis: "`nix flake check` logs the checks"
|
||||
issues: 8882
|
||||
prs: 8893
|
||||
---
|
||||
|
||||
`nix flake check` now logs the checks it runs and the derivations it evaluates:
|
||||
|
||||
```
|
||||
$ nix flake check -v
|
||||
evaluating flake...
|
||||
checking flake output 'checks'...
|
||||
checking derivation 'checks.aarch64-darwin.ghciwatch-tests'...
|
||||
derivation evaluated to /nix/store/nh7dlvsrhds4cxl91mvgj4h5cbq6skmq-ghciwatch-test-0.3.0.drv
|
||||
checking derivation 'checks.aarch64-darwin.ghciwatch-clippy'...
|
||||
derivation evaluated to /nix/store/9cb5a6wmp6kf6hidqw9wphidvb8bshym-ghciwatch-clippy-0.3.0.drv
|
||||
checking derivation 'checks.aarch64-darwin.ghciwatch-doc'...
|
||||
derivation evaluated to /nix/store/8brdd3jbawfszpbs7vdpsrhy80as1il8-ghciwatch-doc-0.3.0.drv
|
||||
checking derivation 'checks.aarch64-darwin.ghciwatch-fmt'...
|
||||
derivation evaluated to /nix/store/wjhs0l1njl5pyji53xlmfjrlya0wmz8p-ghciwatch-fmt-0.3.0.drv
|
||||
checking derivation 'checks.aarch64-darwin.ghciwatch-audit'...
|
||||
derivation evaluated to /nix/store/z0mps8dyj2ds7c0fn0819y5h5611033z-ghciwatch-audit-0.3.0.drv
|
||||
checking flake output 'packages'...
|
||||
checking derivation 'packages.aarch64-darwin.default'...
|
||||
derivation evaluated to /nix/store/41abbdyglw5x9vcsvd89xan3ydjf8d7r-ghciwatch-0.3.0.drv
|
||||
checking flake output 'apps'...
|
||||
checking flake output 'devShells'...
|
||||
checking derivation 'devShells.aarch64-darwin.default'...
|
||||
derivation evaluated to /nix/store/bc935gz7dylzmcpdb5cczr8gngv8pmdb-nix-shell.drv
|
||||
running 5 flake checks...
|
||||
warning: The check omitted these incompatible systems: aarch64-linux, x86_64-darwin, x86_64-linux
|
||||
Use '--all-systems' to check all.
|
||||
```
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
synopsis: "`Overhaul `nix flake update` and `nix flake lock` UX"
|
||||
prs: 8817
|
||||
---
|
||||
|
||||
The interface for creating and updating lock files has been overhauled:
|
||||
|
||||
- [`nix flake lock`](@docroot@/command-ref/new-cli/nix3-flake-lock.md) only creates lock files and adds missing inputs now.
|
||||
It will *never* update existing inputs.
|
||||
|
||||
- [`nix flake update`](@docroot@/command-ref/new-cli/nix3-flake-update.md) does the same, but *will* update inputs.
|
||||
- Passing no arguments will update all inputs of the current flake, just like it already did.
|
||||
- Passing input names as arguments will ensure only those are updated. This replaces the functionality of `nix flake lock --update-input`
|
||||
- To operate on a flake outside the current directory, you must now pass `--flake path/to/flake`.
|
||||
|
||||
- The flake-specific flags `--recreate-lock-file` and `--update-input` have been removed from all commands operating on installables.
|
||||
They are superceded by `nix flake update`.
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
synopsis: "`nix profile` now allows referring to elements by human-readable name, and no longer accepts indices"
|
||||
prs: 8678
|
||||
cls: [978, 980]
|
||||
---
|
||||
|
||||
[`nix profile`](@docroot@/command-ref/new-cli/nix3-profile.md) now uses names to refer to installed packages when running [`list`](@docroot@/command-ref/new-cli/nix3-profile-list.md), [`remove`](@docroot@/command-ref/new-cli/nix3-profile-remove.md) or [`upgrade`](@docroot@/command-ref/new-cli/nix3-profile-upgrade.md) as opposed to indices. Indices have been removed. Profile element names are generated when a package is installed and remain the same until the package is removed.
|
||||
|
||||
**Warning**: The `manifest.nix` file used to record the contents of profiles has changed. Nix will automatically upgrade profiles to the new version when you modify the profile. After that, the profile can no longer be used by older versions of Nix.
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
synopsis: "`builtins.nixVersion` now returns a fixed value \"2.18.3-lix\""
|
||||
cls: 558
|
||||
---
|
||||
|
||||
`builtins.nixVersion` now returns a fixed value `"2.18.3-lix"`. This prevents
|
||||
feature detection assuming that features that exist in Nix post-Lix-branch-off
|
||||
might exist, even though the Lix version is greater than the Nix version.
|
||||
|
||||
In the future, check for builtins for feature detection. If a feature cannot be
|
||||
detected by *those* means, please file a Lix bug.
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
synopsis: re-evaluate cached evaluation errors
|
||||
cls: 771
|
||||
---
|
||||
|
||||
"cached failure of [expr]" errors have been removed: expressions already in the
|
||||
eval cache as a failure will now simply be re-evaluated, removing the need to
|
||||
set `--no-eval-cache` or similar to see the error.
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
synopsis: Coercion errors include the failing value
|
||||
issues: 561
|
||||
prs: 9754
|
||||
---
|
||||
|
||||
The `error: cannot coerce a <TYPE> to a string` message now includes the value
|
||||
which caused the error.
|
||||
|
||||
Before:
|
||||
|
||||
```
|
||||
error: cannot coerce a set to a string
|
||||
```
|
||||
|
||||
After:
|
||||
|
||||
```
|
||||
error: cannot coerce a set to a string: { aesSupport = «thunk»;
|
||||
avx2Support = «thunk»; avx512Support = «thunk»; avxSupport = «thunk»;
|
||||
canExecute = «thunk»; config = «thunk»; darwinArch = «thunk»; darwinMinVersion
|
||||
= «thunk»; darwinMinVersionVariable = «thunk»; darwinPlatform = «thunk»; «84
|
||||
attributes elided»}
|
||||
```
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
synopsis: Type errors include the failing value
|
||||
issues: 561
|
||||
prs: 9753
|
||||
---
|
||||
|
||||
In errors like `value is an integer while a list was expected`, the message now
|
||||
includes the failing value.
|
||||
|
||||
Before:
|
||||
|
||||
```
|
||||
error: value is a set while a string was expected
|
||||
```
|
||||
|
||||
After:
|
||||
|
||||
```
|
||||
error: expected a string but found a set: { ghc810 = «thunk»;
|
||||
ghc8102Binary = «thunk»; ghc8107 = «thunk»; ghc8107Binary = «thunk»;
|
||||
ghc865Binary = «thunk»; ghc90 = «thunk»; ghc902 = «thunk»; ghc92 = «thunk»;
|
||||
ghc924Binary = «thunk»; ghc925 = «thunk»; «17 attributes elided»}
|
||||
```
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
synopsis: "Visual clutter in `--debugger` is reduced"
|
||||
prs: 9919
|
||||
---
|
||||
|
||||
Before:
|
||||
```
|
||||
info: breakpoint reached
|
||||
|
||||
|
||||
Starting REPL to allow you to inspect the current state of the evaluator.
|
||||
|
||||
Welcome to Nix 2.20.0pre20231222_dirty. Type :? for help.
|
||||
|
||||
nix-repl> :continue
|
||||
error: uh oh
|
||||
|
||||
|
||||
Starting REPL to allow you to inspect the current state of the evaluator.
|
||||
|
||||
Welcome to Nix 2.20.0pre20231222_dirty. Type :? for help.
|
||||
|
||||
nix-repl>
|
||||
```
|
||||
|
||||
After:
|
||||
|
||||
```
|
||||
info: breakpoint reached
|
||||
|
||||
Nix 2.20.0pre20231222_dirty debugger
|
||||
Type :? for help.
|
||||
nix-repl> :continue
|
||||
error: uh oh
|
||||
|
||||
nix-repl>
|
||||
```
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
synopsis: Experimental REPL support for documentation comments using `:doc`
|
||||
cls: 564
|
||||
---
|
||||
|
||||
Using `:doc` in the REPL now supports showing documentation comments when defined on a function.
|
||||
|
||||
Previously this was only able to document builtins, however it now will show comments defined on a lambda as well.
|
||||
|
||||
This support is experimental and relies on an embedded version of [nix-doc](https://github.com/lf-/nix-doc).
|
||||
|
||||
The logic also supports limited Markdown formatting of doccomments and should easily support any [RFC 145](https://github.com/NixOS/rfcs/blob/master/rfcs/0145-doc-strings.md)
|
||||
compatible documentation comments in addition to simple commented documentation.
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
synopsis: Add `repl-overlays` option
|
||||
prs: 10203
|
||||
cls: 504
|
||||
---
|
||||
|
||||
A `repl-overlays` option has been added, which specifies files that can overlay
|
||||
and modify the top-level bindings in `nix repl`. For example, with the
|
||||
following contents in `~/.config/nix/repl.nix`:
|
||||
|
||||
```nix
|
||||
info: final: prev: let
|
||||
optionalAttrs = predicate: attrs:
|
||||
if predicate
|
||||
then attrs
|
||||
else {};
|
||||
in
|
||||
optionalAttrs (prev ? legacyPackages && prev.legacyPackages ? ${info.currentSystem})
|
||||
{
|
||||
pkgs = prev.legacyPackages.${info.currentSystem};
|
||||
}
|
||||
```
|
||||
|
||||
We can run `nix repl` and use `pkgs` to refer to `legacyPackages.${currentSystem}`:
|
||||
|
||||
```ShellSession
|
||||
$ nix repl --repl-overlays ~/.config/nix/repl.nix nixpkgs
|
||||
Lix 2.90.0
|
||||
Type :? for help.
|
||||
Loading installable 'flake:nixpkgs#'...
|
||||
Added 5 variables.
|
||||
Loading 'repl-overlays'...
|
||||
Added 6 variables.
|
||||
nix-repl> pkgs.bash
|
||||
«derivation /nix/store/g08b5vkwwh0j8ic9rkmd8mpj878rk62z-bash-5.2p26.drv»
|
||||
```
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
synopsis: reintroduce shortened `-E` form for `--expr` to new CLI
|
||||
cls: 605
|
||||
---
|
||||
|
||||
In the past, it was possible to supply a shorter `-E` flag instead of fully
|
||||
specifying `--expr` every time you wished to provide an expression that would
|
||||
be evaluated to produce the given command's input. This was retained for the
|
||||
`--file` flag when the new CLI utilities were written with `-f`, but `-E` was
|
||||
dropped.
|
||||
|
||||
We now restore the `-E` short form for better UX. This is most useful for
|
||||
`nix eval` but most any command that takes an Installable argument should benefit
|
||||
from it as well.
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
synopsis: "In the debugger, `while evaluating the attribute` errors now include position information"
|
||||
prs: 9915
|
||||
---
|
||||
|
||||
Before:
|
||||
|
||||
```
|
||||
0: while evaluating the attribute 'python311.pythonForBuild.pkgs'
|
||||
0x600001522598
|
||||
```
|
||||
|
||||
After:
|
||||
|
||||
```
|
||||
0: while evaluating the attribute 'python311.pythonForBuild.pkgs'
|
||||
/nix/store/hg65h51xnp74ikahns9hyf3py5mlbbqq-source/overrides/default.nix:132:27
|
||||
|
||||
131|
|
||||
132| bootstrappingBase = pkgs.${self.python.pythonAttr}.pythonForBuild.pkgs;
|
||||
| ^
|
||||
133| in
|
||||
```
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
synopsis: Source locations are printed more consistently in errors
|
||||
issues: 561
|
||||
prs: 9555
|
||||
---
|
||||
|
||||
Source location information is now included in error messages more
|
||||
consistently. Given this code:
|
||||
|
||||
```nix
|
||||
let
|
||||
attr = {foo = "bar";};
|
||||
key = {};
|
||||
in
|
||||
attr.${key}
|
||||
```
|
||||
|
||||
Previously, Nix would show this unhelpful message when attempting to evaluate
|
||||
it:
|
||||
|
||||
```
|
||||
error:
|
||||
… while evaluating an attribute name
|
||||
|
||||
error: value is a set while a string was expected
|
||||
```
|
||||
|
||||
Now, the error message displays where the problematic value was found:
|
||||
|
||||
```
|
||||
error:
|
||||
… while evaluating an attribute name
|
||||
|
||||
at bad.nix:4:11:
|
||||
|
||||
3| key = {};
|
||||
4| in attr.${key}
|
||||
| ^
|
||||
5|
|
||||
|
||||
error: expected a string but found a set: { }
|
||||
```
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
synopsis: Some stack overflow segfaults are fixed
|
||||
issues: 9616
|
||||
prs: 9617
|
||||
---
|
||||
|
||||
The number of nested function calls has been restricted, to detect and report
|
||||
infinite function call recursions. The default maximum call depth is 10,000 and
|
||||
can be set with [the `max-call-depth`
|
||||
option](@docroot@/command-ref/conf-file.md#conf-max-call-depth).
|
||||
|
||||
This fixes segfaults or the following unhelpful error message in many cases:
|
||||
|
||||
error: stack overflow (possible infinite recursion)
|
||||
|
||||
Before:
|
||||
|
||||
```
|
||||
$ nix-instantiate --eval --expr '(x: x x) (x: x x)'
|
||||
Segmentation fault: 11
|
||||
```
|
||||
|
||||
After:
|
||||
|
||||
```
|
||||
$ nix-instantiate --eval --expr '(x: x x) (x: x x)'
|
||||
error: stack overflow
|
||||
|
||||
at «string»:1:14:
|
||||
1| (x: x x) (x: x x)
|
||||
| ^
|
||||
```
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
synopsis: add --store-path argument to `nix upgrade-nix`, to manually specify the Nix to upgrade to
|
||||
cls: 953
|
||||
---
|
||||
|
||||
`nix upgrade-nix` by default downloads a manifest to find the new Nix version to upgrade to, but now you can specify `--store-path` to upgrade Nix to an arbitrary version from the Nix store.
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
synopsis: using `nix profile` on `/nix/var/nix/profiles/default` no longer breaks `nix upgrade-nix`
|
||||
cls: 952
|
||||
---
|
||||
|
||||
On non-NixOS, Nix is conventionally installed into a `nix-env` style profile at /nix/var/nix/profiles/default.
|
||||
Like any `nix-env` profile, using `nix profile` on it automatically migrates it to a `nix profile` style profile, which is incompatible with `nix-env`.
|
||||
`nix upgrade-nix` previously relied solely on `nix-env` to do the upgrade, but now will work fine with either kind of profile.
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
synopsis: Upstart scripts removed
|
||||
cls: 574
|
||||
---
|
||||
|
||||
Upstart scripts have been removed from Lix, since Upstart is obsolete and has
|
||||
not been shipped by any major distributions for many years. If these are
|
||||
necessary to your use case, please back port them to your packaging.
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
synopsis: Better error reporting for `with` expressions
|
||||
prs: 9658
|
||||
---
|
||||
|
||||
`with` expressions using non-attrset values to resolve variables are now reported with proper positions.
|
||||
|
||||
Previously an incorrect `with` expression would report no position at all, making it hard to determine where the error originated:
|
||||
|
||||
```
|
||||
nix-repl> with 1; a
|
||||
error:
|
||||
… <borked>
|
||||
|
||||
at «none»:0: (source not available)
|
||||
|
||||
error: value is an integer while a set was expected
|
||||
```
|
||||
|
||||
Now position information is preserved and reported as with most other errors:
|
||||
|
||||
```
|
||||
nix-repl> with 1; a
|
||||
error:
|
||||
… while evaluating the first subexpression of a with expression
|
||||
at «string»:1:1:
|
||||
1| with 1; a
|
||||
| ^
|
||||
|
||||
error: expected a set but found an integer: 1
|
||||
```
|
||||
+55
-57
@@ -5,17 +5,17 @@
|
||||
- [Installation](installation/installation.md)
|
||||
- [Supported Platforms](installation/supported-platforms.md)
|
||||
- [Installing a Binary Distribution](installation/installing-binary.md)
|
||||
- [Installing Lix from Source](installation/installing-source.md)
|
||||
- [Installing Nix from Source](installation/installing-source.md)
|
||||
- [Prerequisites](installation/prerequisites-source.md)
|
||||
- [Obtaining a Source Distribution](installation/obtaining-source.md)
|
||||
- [Building Lix from Source](installation/building-source.md)
|
||||
- [Using Lix within Docker](installation/installing-docker.md)
|
||||
- [Building Nix from Source](installation/building-source.md)
|
||||
- [Using Nix within Docker](installation/installing-docker.md)
|
||||
- [Security](installation/nix-security.md)
|
||||
- [Single-User Mode](installation/single-user.md)
|
||||
- [Multi-User Mode](installation/multi-user.md)
|
||||
- [Environment Variables](installation/env-variables.md)
|
||||
- [Upgrading Lix](installation/upgrading.md)
|
||||
- [Uninstalling Lix](installation/uninstall.md)
|
||||
- [Upgrading Nix](installation/upgrading.md)
|
||||
- [Uninstalling Nix](installation/uninstall.md)
|
||||
- [Package Management](package-management/package-management.md)
|
||||
- [Basic Package Management](package-management/basic-package-mgmt.md)
|
||||
- [Profiles](package-management/profiles.md)
|
||||
@@ -196,55 +196,53 @@
|
||||
- [C++ style guide](contributing/cxx.md)
|
||||
- [Release Notes](release-notes/release-notes.md)
|
||||
- [Upcoming release](release-notes/rl-next.md)
|
||||
<!-- RELENG-AUTO-INSERTION-MARKER (see releng/release_notes.py) -->
|
||||
- [Lix 2.90 (2024-07-10)](release-notes/rl-2.90.md)
|
||||
- [Nix 2.18 (2023-09-20)](release-notes/rl-2.18.md)
|
||||
- [Nix 2.17 (2023-07-24)](release-notes/rl-2.17.md)
|
||||
- [Nix 2.16 (2023-05-31)](release-notes/rl-2.16.md)
|
||||
- [Nix 2.15 (2023-04-11)](release-notes/rl-2.15.md)
|
||||
- [Nix 2.14 (2023-02-28)](release-notes/rl-2.14.md)
|
||||
- [Nix 2.13 (2023-01-17)](release-notes/rl-2.13.md)
|
||||
- [Nix 2.12 (2022-12-06)](release-notes/rl-2.12.md)
|
||||
- [Nix 2.11 (2022-08-25)](release-notes/rl-2.11.md)
|
||||
- [Nix 2.10 (2022-07-11)](release-notes/rl-2.10.md)
|
||||
- [Nix 2.9 (2022-05-30)](release-notes/rl-2.9.md)
|
||||
- [Nix 2.8 (2022-04-19)](release-notes/rl-2.8.md)
|
||||
- [Nix 2.7 (2022-03-07)](release-notes/rl-2.7.md)
|
||||
- [Nix 2.6 (2022-01-24)](release-notes/rl-2.6.md)
|
||||
- [Nix 2.5 (2021-12-13)](release-notes/rl-2.5.md)
|
||||
- [Nix 2.4 (2021-11-01)](release-notes/rl-2.4.md)
|
||||
- [Nix 2.3 (2019-09-04)](release-notes/rl-2.3.md)
|
||||
- [Nix 2.2 (2019-01-11)](release-notes/rl-2.2.md)
|
||||
- [Nix 2.1 (2018-09-02)](release-notes/rl-2.1.md)
|
||||
- [Nix 2.0 (2018-02-22)](release-notes/rl-2.0.md)
|
||||
- [Nix 1.11.10 (2017-06-12)](release-notes/rl-1.11.10.md)
|
||||
- [Nix 1.11 (2016-01-19)](release-notes/rl-1.11.md)
|
||||
- [Nix 1.10 (2015-09-03)](release-notes/rl-1.10.md)
|
||||
- [Nix 1.9 (2015-06-12)](release-notes/rl-1.9.md)
|
||||
- [Nix 1.8 (2014-12-14)](release-notes/rl-1.8.md)
|
||||
- [Nix 1.7 (2014-04-11)](release-notes/rl-1.7.md)
|
||||
- [Nix 1.6.1 (2013-10-28)](release-notes/rl-1.6.1.md)
|
||||
- [Nix 1.6 (2013-09-10)](release-notes/rl-1.6.md)
|
||||
- [Nix 1.5.2 (2013-05-13)](release-notes/rl-1.5.2.md)
|
||||
- [Nix 1.5 (2013-02-27)](release-notes/rl-1.5.md)
|
||||
- [Nix 1.4 (2013-02-26)](release-notes/rl-1.4.md)
|
||||
- [Nix 1.3 (2013-01-04)](release-notes/rl-1.3.md)
|
||||
- [Nix 1.2 (2012-12-06)](release-notes/rl-1.2.md)
|
||||
- [Nix 1.1 (2012-07-18)](release-notes/rl-1.1.md)
|
||||
- [Nix 1.0 (2012-05-11)](release-notes/rl-1.0.md)
|
||||
- [Nix 0.16 (2010-08-17)](release-notes/rl-0.16.md)
|
||||
- [Nix 0.15 (2010-03-17)](release-notes/rl-0.15.md)
|
||||
- [Nix 0.14 (2010-02-04)](release-notes/rl-0.14.md)
|
||||
- [Nix 0.13 (2009-11-05)](release-notes/rl-0.13.md)
|
||||
- [Nix 0.12 (2008-11-20)](release-notes/rl-0.12.md)
|
||||
- [Nix 0.11 (2007-12-31)](release-notes/rl-0.11.md)
|
||||
- [Nix 0.10.1 (2006-10-11)](release-notes/rl-0.10.1.md)
|
||||
- [Nix 0.10 (2006-10-06)](release-notes/rl-0.10.md)
|
||||
- [Nix 0.9.2 (2005-09-21)](release-notes/rl-0.9.2.md)
|
||||
- [Nix 0.9.1 (2005-09-20)](release-notes/rl-0.9.1.md)
|
||||
- [Nix 0.9 (2005-09-16)](release-notes/rl-0.9.md)
|
||||
- [Nix 0.8.1 (2005-04-13)](release-notes/rl-0.8.1.md)
|
||||
- [Nix 0.8 (2005-04-11)](release-notes/rl-0.8.md)
|
||||
- [Nix 0.7 (2005-01-12)](release-notes/rl-0.7.md)
|
||||
- [Nix 0.6 (2004-11-14)](release-notes/rl-0.6.md)
|
||||
- [Nix 0.5 and earlier](release-notes/rl-0.5.md)
|
||||
- [Release 2.18 (2023-09-20)](release-notes/rl-2.18.md)
|
||||
- [Release 2.17 (2023-07-24)](release-notes/rl-2.17.md)
|
||||
- [Release 2.16 (2023-05-31)](release-notes/rl-2.16.md)
|
||||
- [Release 2.15 (2023-04-11)](release-notes/rl-2.15.md)
|
||||
- [Release 2.14 (2023-02-28)](release-notes/rl-2.14.md)
|
||||
- [Release 2.13 (2023-01-17)](release-notes/rl-2.13.md)
|
||||
- [Release 2.12 (2022-12-06)](release-notes/rl-2.12.md)
|
||||
- [Release 2.11 (2022-08-25)](release-notes/rl-2.11.md)
|
||||
- [Release 2.10 (2022-07-11)](release-notes/rl-2.10.md)
|
||||
- [Release 2.9 (2022-05-30)](release-notes/rl-2.9.md)
|
||||
- [Release 2.8 (2022-04-19)](release-notes/rl-2.8.md)
|
||||
- [Release 2.7 (2022-03-07)](release-notes/rl-2.7.md)
|
||||
- [Release 2.6 (2022-01-24)](release-notes/rl-2.6.md)
|
||||
- [Release 2.5 (2021-12-13)](release-notes/rl-2.5.md)
|
||||
- [Release 2.4 (2021-11-01)](release-notes/rl-2.4.md)
|
||||
- [Release 2.3 (2019-09-04)](release-notes/rl-2.3.md)
|
||||
- [Release 2.2 (2019-01-11)](release-notes/rl-2.2.md)
|
||||
- [Release 2.1 (2018-09-02)](release-notes/rl-2.1.md)
|
||||
- [Release 2.0 (2018-02-22)](release-notes/rl-2.0.md)
|
||||
- [Release 1.11.10 (2017-06-12)](release-notes/rl-1.11.10.md)
|
||||
- [Release 1.11 (2016-01-19)](release-notes/rl-1.11.md)
|
||||
- [Release 1.10 (2015-09-03)](release-notes/rl-1.10.md)
|
||||
- [Release 1.9 (2015-06-12)](release-notes/rl-1.9.md)
|
||||
- [Release 1.8 (2014-12-14)](release-notes/rl-1.8.md)
|
||||
- [Release 1.7 (2014-04-11)](release-notes/rl-1.7.md)
|
||||
- [Release 1.6.1 (2013-10-28)](release-notes/rl-1.6.1.md)
|
||||
- [Release 1.6 (2013-09-10)](release-notes/rl-1.6.md)
|
||||
- [Release 1.5.2 (2013-05-13)](release-notes/rl-1.5.2.md)
|
||||
- [Release 1.5 (2013-02-27)](release-notes/rl-1.5.md)
|
||||
- [Release 1.4 (2013-02-26)](release-notes/rl-1.4.md)
|
||||
- [Release 1.3 (2013-01-04)](release-notes/rl-1.3.md)
|
||||
- [Release 1.2 (2012-12-06)](release-notes/rl-1.2.md)
|
||||
- [Release 1.1 (2012-07-18)](release-notes/rl-1.1.md)
|
||||
- [Release 1.0 (2012-05-11)](release-notes/rl-1.0.md)
|
||||
- [Release 0.16 (2010-08-17)](release-notes/rl-0.16.md)
|
||||
- [Release 0.15 (2010-03-17)](release-notes/rl-0.15.md)
|
||||
- [Release 0.14 (2010-02-04)](release-notes/rl-0.14.md)
|
||||
- [Release 0.13 (2009-11-05)](release-notes/rl-0.13.md)
|
||||
- [Release 0.12 (2008-11-20)](release-notes/rl-0.12.md)
|
||||
- [Release 0.11 (2007-12-31)](release-notes/rl-0.11.md)
|
||||
- [Release 0.10.1 (2006-10-11)](release-notes/rl-0.10.1.md)
|
||||
- [Release 0.10 (2006-10-06)](release-notes/rl-0.10.md)
|
||||
- [Release 0.9.2 (2005-09-21)](release-notes/rl-0.9.2.md)
|
||||
- [Release 0.9.1 (2005-09-20)](release-notes/rl-0.9.1.md)
|
||||
- [Release 0.9 (2005-09-16)](release-notes/rl-0.9.md)
|
||||
- [Release 0.8.1 (2005-04-13)](release-notes/rl-0.8.1.md)
|
||||
- [Release 0.8 (2005-04-11)](release-notes/rl-0.8.md)
|
||||
- [Release 0.7 (2005-01-12)](release-notes/rl-0.7.md)
|
||||
- [Release 0.6 (2004-11-14)](release-notes/rl-0.6.md)
|
||||
- [Release 0.5 and earlier](release-notes/rl-0.5.md)
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# Tuning Cores and Jobs
|
||||
|
||||
Lix has two relevant settings with regards to how your CPU cores will
|
||||
Nix has two relevant settings with regards to how your CPU cores will
|
||||
be utilized: `cores` and `max-jobs`. This chapter will talk about what
|
||||
they are, how they interact, and their configuration trade-offs.
|
||||
|
||||
- `max-jobs`\
|
||||
Dictates how many separate derivations will be built at the same
|
||||
time. If you set this to zero, the local machine will do no
|
||||
builds. Lix will still substitute from binary caches, and build
|
||||
builds. Nix will still substitute from binary caches, and build
|
||||
remotely if remote builders are configured.
|
||||
|
||||
- `cores`\
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Verifying Build Reproducibility
|
||||
|
||||
You can use Lix's `diff-hook` setting to compare build results. Note
|
||||
You can use Nix's `diff-hook` setting to compare build results. Note
|
||||
that this hook is only executed if the results differ; it is not used
|
||||
for determining if the results are the same.
|
||||
|
||||
@@ -44,7 +44,7 @@ built.
|
||||
Verify a path which already exists in the Nix store by passing `--check`
|
||||
to the build command.
|
||||
|
||||
If the build passes and is deterministic, Lix will exit with a status
|
||||
If the build passes and is deterministic, Nix will exit with a status
|
||||
code of 0:
|
||||
|
||||
```console
|
||||
@@ -59,7 +59,7 @@ checking outputs of '/nix/store/z98fasz2jqy9gs0xbvdj939p27jwda38-stable.drv'...
|
||||
/nix/store/yyxlzw3vqaas7wfp04g0b1xg51f2czgq-stable
|
||||
```
|
||||
|
||||
If the build is not deterministic, Lix will exit with a status code of
|
||||
If the build is not deterministic, Nix will exit with a status code of
|
||||
1:
|
||||
|
||||
```console
|
||||
@@ -75,7 +75,7 @@ error: derivation '/nix/store/cgl13lbj1w368r5z8gywipl1ifli7dhk-unstable.drv' may
|
||||
not be deterministic: output '/nix/store/krpqk0l9ib0ibi1d2w52z293zw455cap-unstable' differs
|
||||
```
|
||||
|
||||
In the Lix daemon's log, we will now see:
|
||||
In the Nix daemon's log, we will now see:
|
||||
|
||||
```
|
||||
For derivation /nix/store/cgl13lbj1w368r5z8gywipl1ifli7dhk-unstable.drv:
|
||||
@@ -85,7 +85,7 @@ For derivation /nix/store/cgl13lbj1w368r5z8gywipl1ifli7dhk-unstable.drv:
|
||||
> 30204
|
||||
```
|
||||
|
||||
Using `--check` with `--keep-failed` will cause Lix to keep the second
|
||||
Using `--check` with `--keep-failed` will cause Nix to keep the second
|
||||
build's output in a special, `.check` path:
|
||||
|
||||
```console
|
||||
@@ -98,7 +98,7 @@ from '/nix/store/krpqk0l9ib0ibi1d2w52z293zw455cap-unstable.check'
|
||||
```
|
||||
|
||||
In particular, notice the
|
||||
`/nix/store/krpqk0l9ib0ibi1d2w52z293zw455cap-unstable.check` output. Lix
|
||||
`/nix/store/krpqk0l9ib0ibi1d2w52z293zw455cap-unstable.check` output. Nix
|
||||
has copied the build results to that directory where you can examine it.
|
||||
|
||||
> []{#check-dirs-are-unregistered} **Note**
|
||||
@@ -114,7 +114,7 @@ has copied the build results to that directory where you can examine it.
|
||||
> build was not deterministic and also a check path does not exist.
|
||||
|
||||
`--check` is only usable if the derivation has been built on the system
|
||||
already. If the derivation has not been built Lix will fail with the
|
||||
already. If the derivation has not been built Nix will fail with the
|
||||
error:
|
||||
|
||||
error: some outputs of '/nix/store/hzi1h60z2qf0nb85iwnpvrai3j2w7rr6-unstable.drv'
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Remote Builds
|
||||
|
||||
Lix supports remote builds, where a local Lix installation can forward
|
||||
Nix supports remote builds, where a local Nix installation can forward
|
||||
Nix builds to other machines. This allows multiple builds to be
|
||||
performed in parallel and allows Lix to perform multi-platform builds in
|
||||
performed in parallel and allows Nix to perform multi-platform builds in
|
||||
a semi-transparent way. For instance, if you perform a build for a
|
||||
`x86_64-darwin` on an `i686-linux` machine, Lix can automatically
|
||||
`x86_64-darwin` on an `i686-linux` machine, Nix can automatically
|
||||
forward the build to a `x86_64-darwin` machine, if available.
|
||||
|
||||
To forward a build to a remote machine, it’s required that the remote
|
||||
@@ -38,15 +38,12 @@ contains Nix.
|
||||
|
||||
> **Warning**
|
||||
>
|
||||
> If you are building via the Lix daemon (default on Linux and macOS), it is the Lix daemon user account (that is, `root`) that should have SSH access to a user (not necessarily `root`) on the remote machine.
|
||||
>
|
||||
> Furthermore, `root` needs to have the public host keys for the remote system in its `.ssh/known_hosts`.
|
||||
> To add them to `known_hosts` for root, do `ssh-keyscan USER@HOST | sudo tee -a ~root/.ssh/known_hosts`.
|
||||
> If you are building via the Nix daemon, it is the Nix daemon user account (that is, `root`) that should have SSH access to a user (not necessarily `root`) on the remote machine.
|
||||
>
|
||||
> If you can’t or don’t want to configure `root` to be able to access the remote machine, you can use a private Nix store instead by passing e.g. `--store ~/my-nix` when running a Nix command from the local machine.
|
||||
|
||||
The list of remote machines can be specified on the command line or in
|
||||
the Lix configuration file. The former is convenient for testing. For
|
||||
the Nix configuration file. The former is convenient for testing. For
|
||||
example, the following command allows you to build a derivation for
|
||||
`x86_64-darwin` on a Linux machine:
|
||||
|
||||
@@ -87,17 +84,17 @@ default, set it to `-`.
|
||||
3. The SSH identity file to be used to log in to the remote machine. If
|
||||
omitted, SSH will use its regular identities.
|
||||
|
||||
4. The maximum number of builds that Lix will execute in parallel on
|
||||
4. The maximum number of builds that Nix will execute in parallel on
|
||||
the machine. Typically this should be equal to the number of CPU
|
||||
cores. For instance, the machine `itchy` in the example will execute
|
||||
up to 8 builds in parallel.
|
||||
|
||||
5. The “speed factor”, indicating the relative speed of the machine. If
|
||||
there are multiple machines of the right type, Lix will prefer the
|
||||
there are multiple machines of the right type, Nix will prefer the
|
||||
fastest, taking load into account.
|
||||
|
||||
6. A comma-separated list of *supported features*. If a derivation has
|
||||
the `requiredSystemFeatures` attribute, then Lix will only perform
|
||||
the `requiredSystemFeatures` attribute, then Nix will only perform
|
||||
the derivation on a machine that has the specified features. For
|
||||
instance, the attribute
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ simple and working example, but it is not suitable for all use cases.
|
||||
The post build hook program runs after each executed build, and blocks
|
||||
the build loop. The build loop exits if the hook program fails.
|
||||
|
||||
Concretely, this implementation will make Lix slow or unusable when the
|
||||
Concretely, this implementation will make Nix slow or unusable when the
|
||||
internet is slow or unreliable.
|
||||
|
||||
A more advanced implementation might pass the store paths to a
|
||||
@@ -76,7 +76,7 @@ Then make sure the hook program is executable by the `root` user:
|
||||
# chmod +x /etc/nix/upload-to-cache.sh
|
||||
```
|
||||
|
||||
# Updating Lix Configuration
|
||||
# Updating Nix Configuration
|
||||
|
||||
Edit `/etc/nix/nix.conf` to run our hook, by adding the following
|
||||
configuration snippet at the end:
|
||||
@@ -119,7 +119,7 @@ warning: you did not specify '--add-root'; the result might be removed by the ga
|
||||
|
||||
# Conclusion
|
||||
|
||||
We now have a Lix installation configured to automatically sign and
|
||||
We now have a Nix installation configured to automatically sign and
|
||||
upload every local build to a remote binary cache.
|
||||
|
||||
Before deploying this to production, be sure to consider the
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Architecture
|
||||
|
||||
This chapter describes how Nix works.
|
||||
It should help users understand why Lix behaves as it does, and it should help developers understand how to modify Lix and how to write similar tools.
|
||||
It should help users understand why Nix behaves as it does, and it should help developers understand how to modify Nix and how to write similar tools.
|
||||
|
||||
## Overview
|
||||
|
||||
@@ -21,8 +21,8 @@ The following [concept map] shows its main components (rectangles), the objects
|
||||
| passed to
|
||||
| |
|
||||
+----------|-------------------|--------------------------------+
|
||||
| Nix impl.| V |
|
||||
| (Lix) | +-------------------------+ |
|
||||
| Nix | V |
|
||||
| | +-------------------------+ |
|
||||
| | | commmand line interface |------. |
|
||||
| | +-------------------------+ | |
|
||||
| | | | |
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# File System Object
|
||||
|
||||
Nix implementations use a simplified model of the file system, which consists of file system objects.
|
||||
Nix uses a simplified model of the file system, which consists of file system objects.
|
||||
Every file system object is one of the following:
|
||||
|
||||
- File
|
||||
@@ -15,7 +15,7 @@ Every file system object is one of the following:
|
||||
- [Symbolic link](https://en.m.wikipedia.org/wiki/Symbolic_link)
|
||||
|
||||
An arbitrary string.
|
||||
Nix implementations do not assign any semantics to symbolic links.
|
||||
Nix does not assign any semantics to symbolic links.
|
||||
|
||||
File system objects and their children form a tree.
|
||||
A bare file or symlink can be a root file system object.
|
||||
|
||||
@@ -1,2 +1,2 @@
|
||||
This section lists commands and options that you can use when you work
|
||||
with Lix.
|
||||
with Nix.
|
||||
|
||||
@@ -1,14 +1,14 @@
|
||||
# Name
|
||||
|
||||
`nix.conf` - Lix configuration file
|
||||
`nix.conf` - Nix configuration file
|
||||
|
||||
# Description
|
||||
|
||||
Lix supports a variety of configuration settings, which are read from configuration files or taken as command line flags.
|
||||
Nix supports a variety of configuration settings, which are read from configuration files or taken as command line flags.
|
||||
|
||||
## Configuration file
|
||||
|
||||
By default Lix reads settings from the following places, in that order:
|
||||
By default Nix reads settings from the following places, in that order:
|
||||
|
||||
1. The system-wide configuration file `sysconfdir/nix/nix.conf` (i.e. `/etc/nix/nix.conf` on most systems), or `$NIX_CONF_DIR/nix.conf` if [`NIX_CONF_DIR`](./env-common.md#env-NIX_CONF_DIR) is set.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Common Environment Variables
|
||||
|
||||
Most commands in Lix interpret the following environment variables:
|
||||
Most Nix commands interpret the following environment variables:
|
||||
|
||||
- <span id="env-IN_NIX_SHELL">[`IN_NIX_SHELL`](#env-IN_NIX_SHELL)</span>\
|
||||
Indicator that tells if the current environment was set up by
|
||||
@@ -13,7 +13,7 @@ Most commands in Lix interpret the following environment variables:
|
||||
e.g. `/home/eelco/Dev:/etc/nixos`. It can be extended using the
|
||||
[`-I` option](@docroot@/command-ref/opt-common.md#opt-I).
|
||||
|
||||
If `NIX_PATH` is not set at all, Lix will fall back to the following list in [impure](@docroot@/command-ref/conf-file.md#conf-pure-eval) and [unrestricted](@docroot@/command-ref/conf-file.md#conf-restrict-eval) evaluation mode:
|
||||
If `NIX_PATH` is not set at all, Nix will fall back to the following list in [impure](@docroot@/command-ref/conf-file.md#conf-pure-eval) and [unrestricted](@docroot@/command-ref/conf-file.md#conf-restrict-eval) evaluation mode:
|
||||
|
||||
1. `$HOME/.nix-defexpr/channels`
|
||||
2. `nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs`
|
||||
@@ -50,28 +50,28 @@ Most commands in Lix interpret the following environment variables:
|
||||
Overrides the location of the Nix store (default `prefix/store`).
|
||||
|
||||
- <span id="env-NIX_DATA_DIR">[`NIX_DATA_DIR`](#env-NIX_DATA_DIR)</span>\
|
||||
Overrides the location of the Lix static data directory (default
|
||||
Overrides the location of the Nix static data directory (default
|
||||
`prefix/share`).
|
||||
|
||||
- <span id="env-NIX_LOG_DIR">[`NIX_LOG_DIR`](#env-NIX_LOG_DIR)</span>\
|
||||
Overrides the location of the Lix log directory (default
|
||||
Overrides the location of the Nix log directory (default
|
||||
`prefix/var/log/nix`).
|
||||
|
||||
- <span id="env-NIX_STATE_DIR">[`NIX_STATE_DIR`](#env-NIX_STATE_DIR)</span>\
|
||||
Overrides the location of the Lix state directory (default
|
||||
Overrides the location of the Nix state directory (default
|
||||
`prefix/var/nix`).
|
||||
|
||||
- <span id="env-NIX_CONF_DIR">[`NIX_CONF_DIR`](#env-NIX_CONF_DIR)</span>\
|
||||
Overrides the location of the system Lix configuration directory
|
||||
Overrides the location of the system Nix configuration directory
|
||||
(default `prefix/etc/nix`).
|
||||
|
||||
- <span id="env-NIX_CONFIG">[`NIX_CONFIG`](#env-NIX_CONFIG)</span>\
|
||||
Applies settings from Lix configuration from the environment.
|
||||
The content is treated as if it was read from a Lix configuration file.
|
||||
Applies settings from Nix configuration from the environment.
|
||||
The content is treated as if it was read from a Nix configuration file.
|
||||
Settings are separated by the newline character.
|
||||
|
||||
- <span id="env-NIX_USER_CONF_FILES">[`NIX_USER_CONF_FILES`](#env-NIX_USER_CONF_FILES)</span>\
|
||||
Overrides the location of the Lix user configuration files to load from.
|
||||
Overrides the location of the Nix user configuration files to load from.
|
||||
|
||||
The default are the locations according to the [XDG Base Directory Specification].
|
||||
See the [XDG Base Directories](#xdg-base-directories) sub-section for details.
|
||||
@@ -84,19 +84,19 @@ Most commands in Lix interpret the following environment variables:
|
||||
substantial amounts of disk space. The default is `/tmp`.
|
||||
|
||||
- <span id="env-NIX_REMOTE">[`NIX_REMOTE`](#env-NIX_REMOTE)</span>\
|
||||
This variable should be set to `daemon` if you want to use the Lix
|
||||
This variable should be set to `daemon` if you want to use the Nix
|
||||
daemon to execute Nix operations. This is necessary in [multi-user
|
||||
Nix installations](@docroot@/installation/multi-user.md). If the Lix
|
||||
Nix installations](@docroot@/installation/multi-user.md). If the Nix
|
||||
daemon's Unix socket is at some non-standard path, this variable
|
||||
should be set to `unix://path/to/socket`. Otherwise, it should be
|
||||
left unset.
|
||||
|
||||
- <span id="env-NIX_SHOW_STATS">[`NIX_SHOW_STATS`](#env-NIX_SHOW_STATS)</span>\
|
||||
If set to `1`, Lix will print some evaluation statistics, such as
|
||||
If set to `1`, Nix will print some evaluation statistics, such as
|
||||
the number of values allocated.
|
||||
|
||||
- <span id="env-NIX_COUNT_CALLS">[`NIX_COUNT_CALLS`](#env-NIX_COUNT_CALLS)</span>\
|
||||
If set to `1`, Lix will print how often functions were called during
|
||||
If set to `1`, Nix will print how often functions were called during
|
||||
Nix expression evaluation. This is useful for profiling your Nix
|
||||
expressions.
|
||||
|
||||
@@ -108,9 +108,9 @@ Most commands in Lix interpret the following environment variables:
|
||||
|
||||
## XDG Base Directories
|
||||
|
||||
Lix follows the [XDG Base Directory Specification].
|
||||
Nix follows the [XDG Base Directory Specification].
|
||||
|
||||
For backwards compatibility, commands in Lix will follow the standard only when [`use-xdg-base-directories`] is enabled.
|
||||
For backwards compatibility, Nix commands will follow the standard only when [`use-xdg-base-directories`] is enabled.
|
||||
[New Nix commands](@docroot@/command-ref/new-cli/nix.md) (experimental) conform to the standard by default.
|
||||
|
||||
The following environment variables are used to determine locations of various state and configuration files:
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Files
|
||||
|
||||
This section lists configuration files that you can use when you work
|
||||
with Lix.
|
||||
with Nix.
|
||||
|
||||
@@ -21,7 +21,7 @@ lrwxrwxrwx 1 alice users 51 Oct 29 13:20 /home/alice/.local/state/nix/profiles/p
|
||||
lrwxrwxrwx 1 alice users 51 Nov 25 14:35 /home/alice/.local/state/nix/profiles/profile-7-link -> /nix/store/mp0x6xnsg0b8qhswy6riqvimai4gm677-profile
|
||||
```
|
||||
|
||||
Each of these symlinks is a root for the Lix garbage collector.
|
||||
Each of these symlinks is a root for the Nix garbage collector.
|
||||
|
||||
The contents of the store path corresponding to each version of the
|
||||
profile is a tree of symlinks to the files of the installed packages,
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Main Commands
|
||||
|
||||
This section lists commands and options that you can use when you work
|
||||
with Lix.
|
||||
with Nix.
|
||||
|
||||
@@ -14,8 +14,9 @@
|
||||
|
||||
# Disambiguation
|
||||
|
||||
This man page describes the command `nix-build`, which is distinct from [`nix build`](./new-cli/nix3-build.md).
|
||||
For documentation on the latter, run `nix build --help` or see `man nix3-build`.
|
||||
This man page describes the command `nix-build`, which is distinct from `nix
|
||||
build`. For documentation on the latter, run `nix build --help` or see `man
|
||||
nix3-build`.
|
||||
|
||||
# Description
|
||||
|
||||
|
||||
@@ -37,9 +37,7 @@ Instead, it looks in a few locations, and acts on all profiles it finds there:
|
||||
> Not stable; subject to change
|
||||
>
|
||||
> Do not rely on this functionality; it just exists for migration purposes and is may change in the future.
|
||||
> These deprecated paths remain a private implementation detail of Lix.
|
||||
|
||||
<!-- FIXME(Qyriad): this is inconsistent with https://git.lix.systems/lix-project/lix/issues/215, needs updating when that happens -->
|
||||
> These deprecated paths remain a private implementation detail of Nix.
|
||||
|
||||
`$NIX_STATE_DIR/profiles` and `$NIX_STATE_DIR/profiles/per-user`.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Name
|
||||
|
||||
`nix-daemon` - Lix multi-user support daemon
|
||||
`nix-daemon` - Nix multi-user support daemon
|
||||
|
||||
# Synopsis
|
||||
|
||||
@@ -8,6 +8,6 @@
|
||||
|
||||
# Description
|
||||
|
||||
The Lix daemon is necessary in multi-user Lix installations. It runs
|
||||
The Nix daemon is necessary in multi-user Nix installations. It runs
|
||||
build tasks and other operations on the Nix store on behalf of
|
||||
unprivileged users.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Common Options
|
||||
|
||||
Most commands in Lix accept the following command-line options:
|
||||
Most Nix commands accept the following command-line options:
|
||||
|
||||
- <span id="opt-help">[`--help`](#opt-help)</span>
|
||||
|
||||
@@ -8,12 +8,12 @@ Most commands in Lix accept the following command-line options:
|
||||
|
||||
- <span id="opt-version">[`--version`](#opt-version)</span>
|
||||
|
||||
Prints out the Lix version number on standard output and exits.
|
||||
Prints out the Nix version number on standard output and exits.
|
||||
|
||||
- <span id="opt-verbose">[`--verbose`](#opt-verbose)</span> / `-v`
|
||||
|
||||
Increases the level of verbosity of diagnostic messages printed on standard error.
|
||||
For each Lix operation, the information printed on standard output is well-defined;
|
||||
For each Nix operation, the information printed on standard output is well-defined;
|
||||
any diagnostic information is printed on standard error, never on standard output.
|
||||
|
||||
This option may be specified repeatedly.
|
||||
@@ -21,11 +21,11 @@ Most commands in Lix accept the following command-line options:
|
||||
|
||||
- `0` “Errors only”
|
||||
|
||||
Only print messages explaining why the Lix invocation failed.
|
||||
Only print messages explaining why the Nix invocation failed.
|
||||
|
||||
- `1` “Informational”
|
||||
|
||||
Print *useful* messages about what Lix is doing.
|
||||
Print *useful* messages about what Nix is doing.
|
||||
This is the default.
|
||||
|
||||
- `2` “Talkative”
|
||||
@@ -80,13 +80,13 @@ Most commands in Lix accept the following command-line options:
|
||||
|
||||
- <span id="opt-no-build-output">[`--no-build-output`](#opt-no-build-output)</span> / `-Q`
|
||||
|
||||
By default, output written by builders to standard output and standard error is echoed to the Lix command's standard error.
|
||||
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error.
|
||||
This option suppresses this behaviour.
|
||||
Note that the builder's standard output and error are always written to a log file in `prefix/nix/var/log/nix`.
|
||||
|
||||
- <span id="opt-max-jobs">[`--max-jobs`](#opt-max-jobs)</span> / `-j` *number*
|
||||
|
||||
Sets the maximum number of build jobs that Lix will perform in parallel to the specified number.
|
||||
Sets the maximum number of build jobs that Nix will perform in parallel to the specified number.
|
||||
Specify `auto` to use the number of CPUs in the system.
|
||||
The default is specified by the `max-jobs` configuration setting, which itself defaults to `1`.
|
||||
A higher value is useful on SMP systems or to exploit I/O latency.
|
||||
@@ -116,8 +116,8 @@ Most commands in Lix accept the following command-line options:
|
||||
- <span id="opt-keep-going">[`--keep-going`](#opt-keep-going)</span> / `-k`
|
||||
|
||||
Keep going in case of failed builds, to the greatest extent possible.
|
||||
That is, if building an input of some derivation fails, Lix will still build the other inputs, but not the derivation itself.
|
||||
Without this option, Lix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
|
||||
That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself.
|
||||
Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
|
||||
|
||||
- <span id="opt-keep-failed">[`--keep-failed`](#opt-keep-failed)</span> / `-K`
|
||||
|
||||
@@ -126,24 +126,18 @@ Most commands in Lix accept the following command-line options:
|
||||
|
||||
- <span id="opt-fallback">[`--fallback`](#opt-fallback)</span>
|
||||
|
||||
Whenever Lix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
|
||||
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
|
||||
|
||||
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository.
|
||||
If the repository is down, the realisation of the derivation will fail.
|
||||
When this option is specified, Lix will build the derivation instead.
|
||||
When this option is specified, Nix will build the derivation instead.
|
||||
Thus, installation from binaries falls back on installation from source.
|
||||
This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
|
||||
|
||||
- <span id="opt-readonly-mode">[`--readonly-mode`](#opt-readonly-mode)</span>
|
||||
|
||||
When this option is used, no attempt is made to open the Lix database.
|
||||
Most Lix operations do need database access, so those operations will fail.
|
||||
|
||||
<div class="warning">
|
||||
|
||||
FIXME(Lix): sometimes you want `--store dummy` instead, because this option sometimes doesn't work. Document why this is.
|
||||
|
||||
</div>
|
||||
When this option is used, no attempt is made to open the Nix database.
|
||||
Most Nix operations do need database access, so those operations will fail.
|
||||
|
||||
- <span id="opt-arg">[`--arg`](#opt-arg)</span> *name* *value*
|
||||
|
||||
@@ -201,8 +195,8 @@ Most commands in Lix accept the following command-line options:
|
||||
|
||||
- <span id="opt-option">[`--option`](#opt-option)</span> *name* *value*
|
||||
|
||||
Set the Lix configuration option *name* to *value*.
|
||||
This overrides settings in the Lix configuration file (see nix.conf(5)).
|
||||
Set the Nix configuration option *name* to *value*.
|
||||
This overrides settings in the Nix configuration file (see nix.conf5).
|
||||
|
||||
- <span id="opt-repair">[`--repair`](#opt-repair)</span>
|
||||
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
# Utilities
|
||||
|
||||
This section lists utilities that you can use when you work with Lix.
|
||||
This section lists utilities that you can use when you work with Nix.
|
||||
|
||||
@@ -11,12 +11,12 @@ follow to ensure a consistent and approachable user experience.
|
||||
`nix` command provides a single entry to a number of sub-commands that help
|
||||
**developers and system administrators** in the life-cycle of a software
|
||||
project. We particularly need to pay special attention to help and assist new
|
||||
users of Lix.
|
||||
users of Nix.
|
||||
|
||||
# Naming the `COMMANDS`
|
||||
|
||||
Words matter. Naming is an important part of the usability. Users will be
|
||||
interacting with Lix on a regular basis so we should **name things for ease of
|
||||
interacting with Nix on a regular basis so we should **name things for ease of
|
||||
understanding**.
|
||||
|
||||
We recommend following the [Principle of Least
|
||||
@@ -184,7 +184,7 @@ Initializing Nix project at `/path/to/here`.
|
||||
### Next steps
|
||||
|
||||
It can be invaluable to newcomers to show what a possible next steps and what
|
||||
is the usual development workflow with Lix. For example:
|
||||
is the usual development workflow with Nix. For example:
|
||||
|
||||
|
||||
```shell
|
||||
@@ -317,7 +317,7 @@ compromise between being terse and being verbose, between showing help to
|
||||
beginners and annoying advance users. For this it is important that we know
|
||||
what are the priorities.
|
||||
|
||||
Lix command line should be first and foremost written with beginners in mind.
|
||||
Nix command line should be first and foremost written with beginners in mind.
|
||||
But users won't stay beginners for long and what was once useful might quickly
|
||||
become annoying. There is no golden rule that we can give in this guideline
|
||||
that would make it easier how to draw a line and find best compromise.
|
||||
@@ -331,7 +331,7 @@ certain `OPTIONS`, etc…)
|
||||
|
||||
## Follow best practices
|
||||
|
||||
Needless to say we Lix must be a good citizen and follow best practices in
|
||||
Needless to say we Nix must be a good citizen and follow best practices in
|
||||
command line.
|
||||
|
||||
In short: **STDOUT is for output, STDERR is for (human) messaging.**
|
||||
@@ -462,7 +462,7 @@ However, simply converting everything to records is not enough, because the orde
|
||||
{ "outputs": { "bin": {}, "out": {} } }
|
||||
```
|
||||
|
||||
The first item is the default output. Deriving this information from the outputs ordering is not great, but this is how Lix currently happens to work.
|
||||
The first item is the default output. Deriving this information from the outputs ordering is not great, but this is how Nix currently happens to work.
|
||||
While it is possible for a JSON parser to preserve the order of fields, we can not rely on this capability to be present in all JSON libraries.
|
||||
|
||||
This representation is extensible and preserves the ordering:
|
||||
|
||||
@@ -1,11 +1,4 @@
|
||||
This section describes the notion of *experimental features*, and how it fits into the big picture of the development of Lix.
|
||||
|
||||
<div class="warning">
|
||||
|
||||
This section has not been updated for Lix *development practices* and should not be considered authoritative with respect to those; see the Lix wiki for more up-to-date information as it gets written <https://wiki.lix.systems/books/lix-contributors>. The technical content on this page is correct.
|
||||
|
||||
</div>
|
||||
|
||||
This section describes the notion of *experimental features*, and how it fits into the big picture of the development of Nix.
|
||||
|
||||
# What are experimental features?
|
||||
|
||||
@@ -19,7 +12,7 @@ This was a source of confusion and controversy.
|
||||
|
||||
# When should a new feature be marked experimental?
|
||||
|
||||
A change in the Lix codebase should be guarded by an experimental feature flag if it is considered likely to be reverted or adapted in a backwards-incompatible manner after gathering more experience with it in practice.
|
||||
A change in the Nix codebase should be guarded by an experimental feature flag if it is considered likely to be reverted or adapted in a backwards-incompatible manner after gathering more experience with it in practice.
|
||||
|
||||
Examples:
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Hacking
|
||||
|
||||
This section provides some notes on how to hack on Lix. To get the latest version of Lix from Forgejo:
|
||||
This section provides some notes on how to hack on Nix. To get the latest version of Lix from Forgejo:
|
||||
|
||||
```console
|
||||
$ git clone https://git.lix.systems/lix-project/lix
|
||||
@@ -102,14 +102,14 @@ $ meson compile -C build nixexpr
|
||||
All targets may be addressed as their output, relative to the build directory, e.g.:
|
||||
|
||||
```bash
|
||||
$ meson compile -C build src/libexpr/liblixexpr.so
|
||||
$ meson compile -C build src/libexpr/libnixexpr.so
|
||||
```
|
||||
|
||||
But Meson does not consider intermediate files like object files targets.
|
||||
To build a specific object file, use Ninja directly and specify the output file relative to the build directory:
|
||||
|
||||
```bash
|
||||
$ ninja -C build src/libexpr/liblixexpr.so.p/nixexpr.cc.o
|
||||
$ ninja -C build src/libexpr/libnixexpr.so.p/nixexpr.cc.o
|
||||
```
|
||||
|
||||
To inspect the canonical source of truth on what the state of the buildsystem configuration is, use:
|
||||
@@ -120,13 +120,13 @@ $ meson introspect
|
||||
|
||||
## Building Lix outside of development shells
|
||||
|
||||
To build a release version of Lix for the current operating system and CPU architecture:
|
||||
To build a release version of Nix for the current operating system and CPU architecture:
|
||||
|
||||
```console
|
||||
$ nix build
|
||||
```
|
||||
|
||||
You can also build Lix for one of the [supported platforms](#platforms).
|
||||
You can also build Nix for one of the [supported platforms](#platforms).
|
||||
|
||||
> **Note**
|
||||
>
|
||||
@@ -135,9 +135,9 @@ You can also build Lix for one of the [supported platforms](#platforms).
|
||||
|
||||
## Platforms
|
||||
|
||||
Lix can be built for various platforms, as specified in [`flake.nix`]:
|
||||
Nix can be built for various platforms, as specified in [`flake.nix`]:
|
||||
|
||||
[`flake.nix`]: https://git.lix.systems/lix-project/lix/src/branch/main/flake.nix
|
||||
[`flake.nix`]: https://github.com/nixos/nix/blob/master/flake.nix
|
||||
|
||||
- `x86_64-linux`
|
||||
- `x86_64-darwin`
|
||||
@@ -147,7 +147,7 @@ Lix can be built for various platforms, as specified in [`flake.nix`]:
|
||||
- `armv6l-linux`
|
||||
- `armv7l-linux`
|
||||
|
||||
In order to build Lix for a different platform than the one you're currently
|
||||
In order to build Nix for a different platform than the one you're currently
|
||||
on, you need a way for your current Nix installation to build code for that
|
||||
platform. Common solutions include [remote builders] and [binary format emulation]
|
||||
(only supported on NixOS).
|
||||
@@ -196,7 +196,7 @@ Lix uses a string with the following format to identify the *system type* or *pl
|
||||
<cpu>-<os>[-<abi>]
|
||||
```
|
||||
|
||||
It is set when Lix is compiled for the given system, and determined by [Meson's `host_machine.cpu_family()` and `host_machine.system()` values](https://mesonbuild.com/Reference-manual_builtin_host_machine.html).
|
||||
It is set when Nix is compiled for the given system, and determined by [Meson's `host_machine.cpu_family()` and `host_machine.system()` values](https://mesonbuild.com/Reference-manual_builtin_host_machine.html).
|
||||
|
||||
For historic reasons and backward-compatibility, some CPU and OS identifiers are translated from the GNU Autotools naming convention in [`meson.build`](https://git.lix.systems/lix-project/lix/blob/main/meson.build) as follows:
|
||||
|
||||
@@ -212,7 +212,7 @@ For historic reasons and backward-compatibility, some CPU and OS identifiers are
|
||||
|
||||
## Compilation environments
|
||||
|
||||
Lix can be compiled using multiple environments:
|
||||
Nix can be compiled using multiple environments:
|
||||
|
||||
- `stdenv`: default;
|
||||
- `gccStdenv`: force the use of `gcc` compiler;
|
||||
@@ -325,13 +325,8 @@ Here's what a complete entry looks like. The file name is not incorporated in th
|
||||
```
|
||||
---
|
||||
synopsis: Basically a title
|
||||
# 1234 or gh#1234 will refer to CppNix GitHub, fj#1234 will refer to a Lix forgejo issue.
|
||||
issues: [1234, fj#1234]
|
||||
# Use this *only* if there is a CppNix pull request associated with this change
|
||||
issues: 1234
|
||||
prs: 1238
|
||||
# List of Lix Gerrit changelist numbers; if there is an associated Lix GitHub
|
||||
# PR, just put in the Gerrit CL number.
|
||||
cls: [123]
|
||||
---
|
||||
|
||||
Here's one or more paragraphs that describe the change.
|
||||
|
||||
@@ -12,55 +12,41 @@ The unit tests are defined using the [googletest] and [rapidcheck] frameworks.
|
||||
> An example of some files, demonstrating much of what is described below
|
||||
>
|
||||
> ```
|
||||
> src
|
||||
> ├── libexpr
|
||||
> │ ├── value/context.hh
|
||||
> │ ├── value/context.cc
|
||||
> │ │
|
||||
> │ …
|
||||
> └── tests
|
||||
> │ ├── value/context.hh
|
||||
> │ ├── value/context.cc
|
||||
> │ │
|
||||
> │ …
|
||||
> │
|
||||
> ├── unit-test-data
|
||||
> │ ├── libstore
|
||||
> │ │ ├── worker-protocol/content-address.bin
|
||||
> │ │ …
|
||||
> │ …
|
||||
> …
|
||||
> ├── src
|
||||
> │ ├── libexpr
|
||||
> │ │ ├── …
|
||||
> │ │ ├── value
|
||||
> │ │ │ ├── context.cc
|
||||
> │ │ │ └── context.hh
|
||||
> │ … …
|
||||
> ├── tests
|
||||
> │ …
|
||||
> │ └── unit
|
||||
> │ ├── libcmd
|
||||
> │ │ └── args.cc
|
||||
> │ ├── libexpr
|
||||
> │ │ ├── …
|
||||
> │ │ └── value
|
||||
> │ │ ├── context.cc
|
||||
> │ │ └── print.cc
|
||||
> │ ├── libexpr-support
|
||||
> │ │ └── tests
|
||||
> │ │ ├── libexpr.hh
|
||||
> │ │ └── value
|
||||
> │ │ ├── context.cc
|
||||
> │ │ └── context.hh
|
||||
> │ ├── libstore
|
||||
> │ │ ├── common-protocol.cc
|
||||
> │ │ ├── data
|
||||
> │ │ │ ├── libstore
|
||||
> │ │ │ │ ├── common-protocol
|
||||
> │ │ │ │ │ ├── content-address.bin
|
||||
> │ │ │ │ │ ├── drv-output.bin
|
||||
> … … … … … …
|
||||
> ```
|
||||
|
||||
The unit tests for each Lix library (`liblixexpr`, `liblixstore`, etc..) live inside a directory `src/${library_shortname}/tests` within the directory for the library (`src/${library_shortname}`).
|
||||
The unit tests for each Nix library (`libnixexpr`, `libnixstore`, etc..) live inside a directory `src/${library_shortname}/tests` within the directory for the library (`src/${library_shortname}`).
|
||||
|
||||
The data is in `tests/unit/LIBNAME/data/LIBNAME`, with one subdir per library, with the same name as where the code goes.
|
||||
For example, `liblixstore` code is in `src/libstore`, and its test data is in `tests/unit/libstore/data/libstore`.
|
||||
The path to the unit test data directory is passed to the unit test executable with the environment variable `_NIX_TEST_UNIT_DATA`.
|
||||
The data is in `unit-test-data`, with one subdir per library, with the same name as where the code goes.
|
||||
For example, `libnixstore` code is in `src/libstore`, and its test data is in `unit-test-data/libstore`.
|
||||
The path to the `unit-test-data` directory is passed to the unit test executable with the environment variable `_NIX_TEST_UNIT_DATA`.
|
||||
|
||||
> **Note**
|
||||
> Due to the way googletest works, downstream unit test executables will actually include and re-run upstream library tests.
|
||||
> Therefore it is important that the same value for `_NIX_TEST_UNIT_DATA` be used with the tests for each library.
|
||||
> That is why we have the test data nested within a single `unit-test-data` directory.
|
||||
|
||||
### Running tests
|
||||
|
||||
You can run the whole testsuite with `just test` (see justfile for exact invocation of meson), and if you want to run just one test suite, use `just test --suite installcheck functional-init` where `installcheck` is the name of the test suite in this case and `functional-init` is the name of the test.
|
||||
|
||||
To get a list of tests, use `meson test -C build --list` (or `just test --list` for short).
|
||||
|
||||
For `installcheck` specifically, first run `just install` before running the test suite (this is due to meson limitations that don't let us put a dependency on installing before doing the test).
|
||||
|
||||
Finer-grained filtering within a test suite is also possible using the [--gtest_filter](https://google.github.io/googletest/advanced.html#running-a-subset-of-the-tests) command-line option to a test suite executable, or the `GTEST_FILTER` environment variable.
|
||||
You can run the whole testsuite with `make check`, or the tests for a specific component with `make libfoo-tests_RUN`.
|
||||
Finer-grained filtering is also possible using the [--gtest_filter](https://google.github.io/googletest/advanced.html#running-a-subset-of-the-tests) command-line option, or the `GTEST_FILTER` environment variable.
|
||||
|
||||
### Unit test support libraries
|
||||
|
||||
@@ -81,36 +67,24 @@ See [below](#characterization-testing-1) for a broader discussion of characteriz
|
||||
Like with the functional characterization, `_NIX_TEST_ACCEPT=1` is also used.
|
||||
For example:
|
||||
```shell-session
|
||||
$ _NIX_TEST_ACCEPT=1 just test --suite check libstore-unit-tests
|
||||
$ _NIX_TEST_ACCEPT=1 make libstore-tests-exe_RUN
|
||||
...
|
||||
../tests/unit/libstore/common-protocol.cc:27: Skipped
|
||||
Cannot read golden master because another test is also updating it
|
||||
|
||||
../tests/unit/libstore/common-protocol.cc:62: Skipped
|
||||
Updating golden master
|
||||
|
||||
../tests/unit/libstore/common-protocol.cc:27: Skipped
|
||||
Cannot read golden master because another test is also updating it
|
||||
|
||||
../tests/unit/libstore/common-protocol.cc:62: Skipped
|
||||
Updating golden master
|
||||
[ SKIPPED ] WorkerProtoTest.string_read
|
||||
[ SKIPPED ] WorkerProtoTest.string_write
|
||||
[ SKIPPED ] WorkerProtoTest.storePath_read
|
||||
[ SKIPPED ] WorkerProtoTest.storePath_write
|
||||
...
|
||||
```
|
||||
will regenerate the "golden master" expected result for the `liblixstore` characterization tests.
|
||||
will regenerate the "golden master" expected result for the `libnixstore` characterization tests.
|
||||
The characterization tests will mark themselves "skipped" since they regenerated the expected result instead of actually testing anything.
|
||||
|
||||
## Functional tests
|
||||
|
||||
The functional tests reside under the `tests/functional` directory and are listed in `tests/functional/meson.build`.
|
||||
The functional tests reside under the `tests/functional` directory and are listed in `tests/functional/local.mk`.
|
||||
Each test is a bash script.
|
||||
|
||||
### Running the whole test suite
|
||||
|
||||
<div class="warning">
|
||||
FIXME(meson): this section is wrong for meson and commented out accordingly. See "Running Tests" above, and ask the Lix team if you need further clarification.
|
||||
</div>
|
||||
|
||||
<!--
|
||||
The whole test suite can be run with:
|
||||
|
||||
```shell-session
|
||||
@@ -174,8 +148,6 @@ output from bar
|
||||
|
||||
The test script will then be traced with `set -x` and the output displayed as it happens, regardless of whether the test succeeds or fails.
|
||||
|
||||
-->
|
||||
|
||||
### Debugging failing functional tests
|
||||
|
||||
When a functional test fails, it usually does so somewhere in the middle of the script.
|
||||
@@ -198,10 +170,6 @@ edit it like so:
|
||||
bar
|
||||
```
|
||||
|
||||
<div class="warning">
|
||||
FIXME(meson): the command here is incorrect for meson and this whole functionality may need rebuilding.
|
||||
</div>
|
||||
|
||||
Then, running the test with `./mk/debug-test.sh` will drop you into GDB once the script reaches that point:
|
||||
|
||||
```shell-session
|
||||
@@ -218,8 +186,8 @@ For example, enter `run` to start the Nix invocation.
|
||||
|
||||
### Characterization testing
|
||||
|
||||
Occasionally, Lix utilizes a technique called [Characterization Testing](https://en.wikipedia.org/wiki/Characterization_test) as part of the functional tests.
|
||||
This technique is to include the exact output/behavior of a former version of Nix in a test in order to check that Lix continues to produce the same behavior going forward.
|
||||
Occasionally, Nix utilizes a technique called [Characterization Testing](https://en.wikipedia.org/wiki/Characterization_test) as part of the functional tests.
|
||||
This technique is to include the exact output/behavior of a former version of Nix in a test in order to check that Nix continues to produce the same behavior going forward.
|
||||
|
||||
For example, this technique is used for the language tests, to check both the printed final value if evaluation was successful, and any errors and warnings encountered.
|
||||
|
||||
@@ -227,7 +195,7 @@ It is frequently useful to regenerate the expected output.
|
||||
To do that, rerun the failed test(s) with `_NIX_TEST_ACCEPT=1`.
|
||||
For example:
|
||||
```bash
|
||||
_NIX_TEST_ACCEPT=1 just test --suite installcheck -v functional-lang
|
||||
_NIX_TEST_ACCEPT=1 make tests/functional/lang.sh.test
|
||||
```
|
||||
|
||||
An interesting situation to document is the case when these tests are "overfitted".
|
||||
@@ -246,21 +214,14 @@ To ensure that characterization testing doesn't make it harder to intentionally
|
||||
## Integration tests
|
||||
|
||||
The integration tests are defined in the Nix flake under the `hydraJobs.tests` attribute.
|
||||
These tests include everything that needs to interact with external services or run Lix in a non-trivial distributed setup.
|
||||
These tests include everything that needs to interact with external services or run Nix in a non-trivial distributed setup.
|
||||
Because these tests are expensive and require more than what the standard github-actions setup provides, they only run on the master branch (on <https://hydra.nixos.org/jobset/nix/master>).
|
||||
|
||||
You can run them manually with `nix build .#hydraJobs.tests.{testName}` or `nix-build -A hydraJobs.tests.{testName}`
|
||||
|
||||
<div class="warning">
|
||||
|
||||
Installer tests section is outdated and commented out, see https://git.lix.systems/lix-project/lix/issues/33
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
## Installer tests
|
||||
|
||||
After a one-time setup, the Lix repository's GitHub Actions continuous integration (CI) workflow can test the installer each time you push to a branch.
|
||||
After a one-time setup, the Nix repository's GitHub Actions continuous integration (CI) workflow can test the installer each time you push to a branch.
|
||||
|
||||
Creating a Cachix cache for your installer tests and adding its authorization token to GitHub enables [two installer-specific jobs in the CI workflow](https://github.com/NixOS/nix/blob/88a45d6149c0e304f6eb2efcc2d7a4d0d569f8af/.github/workflows/ci.yml#L50-L91):
|
||||
|
||||
@@ -300,7 +261,7 @@ After the CI run completes, you can check the output to extract the installer UR
|
||||
curl -L <install_url> | sh -s -- --tarball-url-prefix https://<github-username>-nix-install-tests.cachix.org/serve
|
||||
```
|
||||
|
||||
<!~~ #### Manually generating test installers
|
||||
<!-- #### Manually generating test installers
|
||||
|
||||
There's obviously a manual way to do this, and it's still the only way for
|
||||
platforms that lack GA runners.
|
||||
@@ -327,138 +288,4 @@ search/replaced in it for each new build.
|
||||
|
||||
The installer now supports a `--tarball-url-prefix` flag which _may_ have
|
||||
solved this need?
|
||||
~~>
|
||||
|
||||
-->
|
||||
|
||||
## Magic environment variables
|
||||
|
||||
FIXME: maybe this section should be moved elsewhere or turned partially into user docs, but I just need a complete index for now.
|
||||
I actually want to ban people calling getenv without writing documentation, and produce a comprehensive list of env-vars used by Lix and enforce it.
|
||||
|
||||
This is a non-exhaustive list of almost all environment variables, magic or not, accepted or used by various parts of the test suite as well as Lix itself.
|
||||
Please add more if you find them.
|
||||
|
||||
I looked for these in the testsuite with the following bad regexes:
|
||||
|
||||
```
|
||||
rg '(?:[^A-Za-z]|^)(_[A-Z][^-\[ }/:");$(]+)' -r '$1' --no-filename --only-matching tests | sort -u > vars.txt
|
||||
rg '\$\{?([A-Z][^-\[ }/:");]+)' -r '$1' --no-filename --only-matching tests | sort -u > vars.txt
|
||||
```
|
||||
|
||||
I grepped `src/` for `get[eE]nv\("` to find the mentions in Lix code.
|
||||
|
||||
### Used by Lix testing support code
|
||||
|
||||
- `_NIX_TEST_ACCEPT` (optional) - Writes out the result of a characterization test as the new expected value.
|
||||
**Expected value**: 1
|
||||
|
||||
- `_NIX_TEST_UNIT_DATA` - The path to the directory for the data for a given unit test suite.
|
||||
|
||||
**Expected value**: `tests/unit/libstore/data/libstore` or similar
|
||||
|
||||
|
||||
### Used by Lix
|
||||
|
||||
- `_NIX_FORCE_HTTP` - Forces file URIs to be treated as remote ones.
|
||||
|
||||
Used by `src/libfetchers/git.cc`, `src/libstore/http-binary-cache-store.cc`,
|
||||
`src/libstore/local-binary-cache-store.cc`. Seems to be for forcing Git
|
||||
clones of `git+file://` URLs, making the HTTP binary
|
||||
cache store accept `file://` URLs (presumably passing them to curl?), and
|
||||
unknown reasons for the local binary cache.
|
||||
|
||||
FIXME(jade): is this obscuring a bug in https://git.lix.systems/lix-project/lix/issues/200?
|
||||
|
||||
**Expected value**: 1
|
||||
- `NIX_ATTRS_SH_FILE`, `NIX_ATTRS_JSON_FILE` (output) - Set by Lix builders; see
|
||||
`structuredAttrs` documentation.
|
||||
- `NIX_BIN_DIR`, `NIX_STORE_DIR` (or its inconsistently-used old alias `NIX_STORE`), `NIX_DATA_DIR`,
|
||||
`NIX_LOG_DIR`, `NIX_LOG_DIR`, `NIX_STATE_DIR`, `NIX_CONF_DIR` -
|
||||
Overrides compile-time configuration of various locations used by Lix. See `src/libstore/globals.cc`.
|
||||
|
||||
**Expected value**: a directory
|
||||
- `NIX_DAEMON_SOCKET_PATH` (optional) - Overrides the daemon socket path from `$NIX_STATE_DIR/daemon-socket/socket`.
|
||||
|
||||
**Expected value**: path to a socket
|
||||
- `NIX_LOG_FD` (output) - An FD number for logs in `internal-json` format to be sent to.
|
||||
Used for, mostly, "setPhase" in nixpkgs setup.sh, but can also be creatively used to print verbose log messages from derivations.
|
||||
|
||||
**Provided value**: number corresponding to an FD in the builder
|
||||
- `NIX_PATH` - Search path for `<whatever>`. Documented elsewhere in the manual.
|
||||
|
||||
**Expected value**: `:` separated list of things that are not necessarily pointing to filesystem paths
|
||||
- `NIX_REMOTE` - The default value of the Lix setting `store`.
|
||||
|
||||
**Expected value**: "daemon", usually. Could be "auto" or any other value acceptable in `store`.
|
||||
- `NIX_BUILD_SHELL` - Documented elsewhere; the shell to invoke with `nix-shell` but not `nix develop`/`nix shell`.
|
||||
The latter ignoring it altogether seems like a bug.
|
||||
|
||||
**Expected value**: the path to an executable shell
|
||||
- `PRINT_PATH` - Undocumented. Used by `nix-prefetch-url` as an alternative form of `--print-path`. Why???
|
||||
- `_NIX_IN_TEST` - If present with any value, makes `fetchClosure` accept file URLs in addition to HTTP ones. Why is this not `_NIX_FORCE_HTTP`??
|
||||
|
||||
Not used anywhere else.
|
||||
- `NIX_ALLOW_EVAL` - Used by eval-cache tests to block evaluation if set to `0`.
|
||||
|
||||
**Expected value**: 1 or 0
|
||||
- `EDITOR` - Used by `editorFor()`, which has some extremely sketchy editor-detection code for jumping to line numbers.
|
||||
- `LISTEN_FDS` and `LISTEN_PID` - Used for systemd socket activation using the systemd socket activation protocol.
|
||||
- `NIX_PAGER` (alternatively, `PAGER`) - Used to select a pager for Lix output. Why does this not use libutil `getEnv()`?
|
||||
- `LESS` (output) - Sets the pager settings for `less` when invoked by Lix.
|
||||
- `NIX_IGNORE_SYMLINK_STORE` - When set, Lix allows the store to be a symlink. Why do we support this?
|
||||
|
||||
Apparently [someone was using it enough to fix it](https://github.com/NixOS/nix/pull/4038).
|
||||
- `NIX_SSL_CERT_FILE` (alternatively, `SSL_CERT_FILE`) - Used to set CA certificates for libcurl.
|
||||
|
||||
**Expected value**: "/etc/ssl/certs/ca-certificates.crt" or similar
|
||||
- `NIX_REMOTE_SYSTEMS` - Used to set `builders`. Can we please deprecate this?
|
||||
- `NIX_USER_CONF_FILES` - `:` separated list of config files to load before
|
||||
`/nix/nix.conf` under each of `XDG_CONFIG_DIRS`.
|
||||
- `NIX_CONFIG` - Newline separated configuration to load into Lix.
|
||||
- `NIX_GET_COMPLETIONS` - Returns completions.
|
||||
Unsure of the exact format, someone should document it; either way my shell never had any completions.
|
||||
|
||||
**Expected value**: number of completions to return.
|
||||
- `IN_SYSTEMD` - Used to switch the logging format so that systemd gets the correct log levels. I think.
|
||||
- `NIX_HELD_LOCKS` - Not used, what is this for?? We should surely remove it right after searching github?
|
||||
- `GC_INITIAL_HEAP_SIZE` - Used to set the initial heap size, processed by boehmgc.
|
||||
- `NIX_COUNT_CALLS` - Documented elsewhere; prints call counts for profiling purposes.
|
||||
- `NIX_SHOW_STATS` - Documented elsewhere; prints various evaluation statistics like function calls, gc info, and similar.
|
||||
- `NIX_SHOW_STATS_PATH` - Writes those statistics into a file at the given path instead of stdout. Undocumented.
|
||||
- `NIX_SHOW_SYMBOLS` - Dumps the symbol table into the show-stats json output.
|
||||
- `TERM` - If `dumb` or unset, disables ANSI colour output.
|
||||
- `NO_COLOR`, `NOCOLOR` - Disables ANSI colour output.
|
||||
- `_NIX_DEVELOPER_SHOW_UNKNOWN_LOCATIONS` - Highlights unknown locations in errors.
|
||||
- `NIX_PROFILE` - Selects which profile `nix-env` will operate on. Documented elsewhere.
|
||||
- `NIX_SSHOPTS` - Options passed to `ssh(1)` when using a ssh remote store.
|
||||
Incorrectly documented on `nix-copy-closure` which is *surely* not the only place they are used??
|
||||
- `_NIX_TEST_NO_LSOF` - Used on non-Linux, non-macOS platforms to disable using `lsof` when finding gc roots.
|
||||
|
||||
Since https://git.lix.systems/lix-project/lix/issues/156 was fixed, this should probably just be removed as it was a bad workaround for a macOS issue.
|
||||
- `_NIX_TEST_GC_SYNC_1` - Path to a pipe that is used to block the GC briefly to validate invariants from the test suite.
|
||||
- `_NIX_TEST_GC_SYNC_2` - Path to a pipe that is used to block the GC briefly to validate invariants from the test suite.
|
||||
- `_NIX_TEST_FREE_SPACE_FILE` - Path to a file containing a decimal number with the free space that the GC is to believe it has.
|
||||
- Various XDG vars
|
||||
- `NIX_DEBUG_SQLITE_TRACES` - Dump all sqlite queries to the log at `notice` level.
|
||||
- `_NIX_TEST_NO_SANDBOX` - Disables actually setting up the sandbox on macOS while leaving other logic the same. Unused on other platforms.
|
||||
- `_NIX_TRACE_BUILT_OUTPUTS` - Dumps all the derivation paths alongside their outputs as lines into a file of the given name.
|
||||
|
||||
### Used by the functional test framework
|
||||
|
||||
- `NIX_DAEMON_PACKAGE` - Runs the test suite against an alternate Nix daemon with the current client.
|
||||
|
||||
**Expected value**: something like `/nix/store/...-nix-2.18.2`
|
||||
- `NIX_CLIENT_PACKAGE` - Runs the test suite against an alternate Nix client with the current daemon.
|
||||
|
||||
**Expected value**: something like `/nix/store/...-nix-2.18.2`
|
||||
- `NIX_TESTS_CA_BY_DEFAULT` - Pass `__contentAddressed`, `outputHashMode` and `outputHashAlgo` to builds of some input-addressed derivations in the test suite.
|
||||
|
||||
**Expected value**: 1
|
||||
- `TEST_DATA` - Not an environment variable! This is used in repl characterization tests to refer to `tests/functional/repl_characterization/data`.
|
||||
More specifically, that path is replaced with the string `$TEST_DATA` in output for reproducibility.
|
||||
- `TEST_HOME` (output) - Set to the temporary directory that is set as `$HOME` inside the tests, underneath `$TEST_ROOT`.
|
||||
- `TEST_ROOT` (output) - Set to the temporary directory that is created for each test to mess with.
|
||||
- `_NIX_TEST_DAEMON_PID` (output) - Used to track the daemon pid to be able to kill it.
|
||||
|
||||
**Provided value**: Daemon pid as a base-10 integer, e.g. 2345
|
||||
|
||||
@@ -57,12 +57,12 @@
|
||||
The location in the file system where store objects live. Typically
|
||||
`/nix/store`.
|
||||
|
||||
From the perspective of the location where Lix is
|
||||
From the perspective of the location where Nix is
|
||||
invoked, the Nix store can be referred to
|
||||
as a "_local_" or a "_remote_" one:
|
||||
|
||||
+ A [local store]{#gloss-local-store} exists on the filesystem of
|
||||
the machine where Lix is invoked. You can use other
|
||||
the machine where Nix is invoked. You can use other
|
||||
local stores by passing the `--store` flag to the
|
||||
`nix` command. Local stores can be used for building derivations.
|
||||
|
||||
@@ -133,7 +133,7 @@
|
||||
|
||||
- [substituter]{#gloss-substituter}
|
||||
|
||||
An additional [store]{#gloss-store} from which Lix can obtain store objects instead of building them.
|
||||
An additional [store]{#gloss-store} from which Nix can obtain store objects instead of building them.
|
||||
Often the substituter is a [binary cache](#gloss-binary-cache), but any store can serve as substituter.
|
||||
|
||||
See the [`substituters` configuration option](./command-ref/conf-file.md#conf-substituters) for details.
|
||||
@@ -159,7 +159,7 @@
|
||||
- [Nix expression]{#gloss-nix-expression}
|
||||
|
||||
A high-level description of software packages and compositions
|
||||
thereof. Deploying software using Lix entails writing Nix
|
||||
thereof. Deploying software using Nix entails writing Nix
|
||||
expressions for your packages. Nix expressions are translated to
|
||||
derivations that are stored in the Nix store. These derivations can
|
||||
then be built.
|
||||
|
||||
@@ -1,13 +1,6 @@
|
||||
# Building Lix from Source
|
||||
# Building Nix from Source
|
||||
|
||||
<div class="warning">
|
||||
|
||||
FIXME(meson): This section is outdated for meson and has been commented out. See https://git.lix.systems/lix-project/lix/issues/258
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
After cloning Lix's Git repository, issue the following commands:
|
||||
After cloning Nix's Git repository, issue the following commands:
|
||||
|
||||
```console
|
||||
$ autoreconf -vfi
|
||||
@@ -36,4 +29,3 @@ Nix keeps its *store* (the place where packages are stored) in
|
||||
|
||||
Nix keeps state (such as its database and log files) in `/nix/var` by
|
||||
default. This can be changed using `--localstatedir=path`.
|
||||
-->
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Environment Variables
|
||||
|
||||
To use Lix, some environment variables should be set. In particular,
|
||||
To use Nix, some environment variables should be set. In particular,
|
||||
`PATH` should contain the directories `prefix/bin` and
|
||||
`~/.nix-profile/bin`. The first directory contains the Nix tools
|
||||
themselves, while `~/.nix-profile` is a symbolic link to the current
|
||||
@@ -16,30 +16,20 @@ source prefix/etc/profile.d/nix.sh
|
||||
|
||||
# `NIX_SSL_CERT_FILE`
|
||||
|
||||
<div class="warning">
|
||||
|
||||
FIXME(Lix): This section is undoubtedly wrong due to the Lix installer being replaced. The definitely-wrong install section has been commented out.
|
||||
|
||||
</div>
|
||||
|
||||
If you need to specify a custom certificate bundle to account for an
|
||||
HTTPS-intercepting man in the middle proxy, you must specify the path to
|
||||
the certificate bundle in the environment variable `NIX_SSL_CERT_FILE`.
|
||||
|
||||
If you don't specify a `NIX_SSL_CERT_FILE` manually, Lix will install
|
||||
If you don't specify a `NIX_SSL_CERT_FILE` manually, Nix will install
|
||||
and use its own certificate bundle.
|
||||
|
||||
<!--
|
||||
|
||||
Set the environment variable and install Lix
|
||||
Set the environment variable and install Nix
|
||||
|
||||
```console
|
||||
$ export NIX_SSL_CERT_FILE=/etc/ssl/my-certificate-bundle.crt
|
||||
$ curl -L https://nixos.org/nix/install | sh
|
||||
```
|
||||
|
||||
-->
|
||||
|
||||
In the shell profile and rc files (for example, `/etc/bashrc`,
|
||||
`/etc/zshrc`), add the following line:
|
||||
|
||||
@@ -49,10 +39,10 @@ export NIX_SSL_CERT_FILE=/etc/ssl/my-certificate-bundle.crt
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> You must not add the export and then do the install, as the Lix
|
||||
> You must not add the export and then do the install, as the Nix
|
||||
> installer will detect the presence of Nix configuration, and abort.
|
||||
|
||||
If you use the Lix daemon, you should also add the following to
|
||||
If you use the Nix daemon, you should also add the following to
|
||||
`/etc/nix/nix.conf`:
|
||||
|
||||
```
|
||||
@@ -61,11 +51,11 @@ ssl-cert-file = /etc/ssl/my-certificate-bundle.crt
|
||||
|
||||
## Proxy Environment Variables
|
||||
|
||||
The Lix installer has special handling for these proxy-related
|
||||
The Nix installer has special handling for these proxy-related
|
||||
environment variables: `http_proxy`, `https_proxy`, `ftp_proxy`,
|
||||
`no_proxy`, `HTTP_PROXY`, `HTTPS_PROXY`, `FTP_PROXY`, `NO_PROXY`.
|
||||
|
||||
If any of these variables are set when running the Lix installer, then
|
||||
If any of these variables are set when running the Nix installer, then
|
||||
the installer will create an override file at
|
||||
`/etc/systemd/system/nix-daemon.service.d/override.conf` so `nix-daemon`
|
||||
will use them.
|
||||
|
||||
@@ -1,15 +1,38 @@
|
||||
# Installation
|
||||
|
||||
See https://lix.systems/install/ for more details.
|
||||
This section describes how to install and configure Nix for first-time use.
|
||||
|
||||
<!--
|
||||
The current recommended option on Linux and MacOS is [multi-user](#multi-user).
|
||||
|
||||
FIXME(Lix): Distributions section is probably good but is definitely outdated as of this writing given nobody has packaged Lix yet (2024-05-05)
|
||||
## Multi-user
|
||||
|
||||
This installation offers better sharing, improved isolation, and more security
|
||||
over a single user installation.
|
||||
|
||||
This option requires either:
|
||||
|
||||
* Linux running systemd, with SELinux disabled
|
||||
* MacOS
|
||||
|
||||
```console
|
||||
$ bash <(curl -L https://nixos.org/nix/install) --daemon
|
||||
```
|
||||
|
||||
## Single-user
|
||||
|
||||
> Single-user is not supported on Mac.
|
||||
|
||||
This installation has less requirements than the multi-user install, however it
|
||||
cannot offer equivalent sharing, isolation, or security.
|
||||
|
||||
This option is suitable for systems without systemd.
|
||||
|
||||
```console
|
||||
$ bash <(curl -L https://nixos.org/nix/install) --no-daemon
|
||||
```
|
||||
|
||||
## Distributions
|
||||
|
||||
The Nix community maintains installers for several distributions.
|
||||
|
||||
They can be found in the [`nix-community/nix-installers`](https://github.com/nix-community/nix-installers) repository.
|
||||
|
||||
-->
|
||||
|
||||
@@ -1,11 +1,5 @@
|
||||
# Installing a Binary Distribution
|
||||
|
||||
See https://lix.systems/install/ for more details.
|
||||
|
||||
<!--
|
||||
|
||||
FIXME(Lix): There are a bunch of technical details on *how* nix is installed in here that we want to keep but it would need serious rewriting.
|
||||
|
||||
The easiest way to install Nix is to run the following command:
|
||||
|
||||
```console
|
||||
@@ -87,7 +81,7 @@ extension. The installer will also create `/etc/profile.d/nix.sh`.
|
||||
# macOS Installation
|
||||
|
||||
[]{#sect-macos-installation-change-store-prefix}[]{#sect-macos-installation-encrypted-volume}[]{#sect-macos-installation-symlink}[]{#sect-macos-installation-recommended-notes}
|
||||
<!~~ Note: anchors above to catch permalinks to old explanations ~~>
|
||||
<!-- Note: anchors above to catch permalinks to old explanations -->
|
||||
|
||||
We believe we have ironed out how to cleanly support the read-only root
|
||||
on modern macOS. New installs will do this automatically.
|
||||
@@ -107,7 +101,7 @@ this to run the installer, but it may help if you run into trouble:
|
||||
- `nobrowse`: prevent the Nix Store volume from showing up on your
|
||||
desktop; also keeps Spotlight from spending resources to index
|
||||
this volume
|
||||
<!~~ TODO:
|
||||
<!-- TODO:
|
||||
- `suid`: honor setuid? surely not? ...
|
||||
- `owners`: honor file ownership on the volume
|
||||
|
||||
@@ -123,7 +117,7 @@ this to run the installer, but it may help if you run into trouble:
|
||||
new reports from coming in. But I hesitate to celebrate because we
|
||||
haven't really named and catalogued the behavior, understood what
|
||||
we're fixing, and validated that all 3 components are essential.
|
||||
~~>
|
||||
-->
|
||||
- if you have FileVault enabled
|
||||
- generate an encryption password
|
||||
- put it in your system Keychain
|
||||
@@ -162,5 +156,3 @@ $ ./install
|
||||
If you need to edit the multi-user installation script to use different
|
||||
group ID or a different user ID range, modify the variables set in the
|
||||
file named `install-multi-user`.
|
||||
|
||||
-->
|
||||
|
||||
@@ -1,62 +1,59 @@
|
||||
# Using Lix within Docker
|
||||
# Using Nix within Docker
|
||||
|
||||
Lix is available on the following two container registries:
|
||||
- [ghcr.io/lix-project/lix](https://ghcr.io/lix-project/lix)
|
||||
- [git.lix.systems/lix-project/lix](https://git.lix.systems/lix-project/-/packages/container/lix)
|
||||
|
||||
To run the latest stable release of Lix with Docker run the following command:
|
||||
To run the latest stable release of Nix with Docker run the following command:
|
||||
|
||||
```console
|
||||
~ » sudo podman run -it ghcr.io/lix-project/lix:latest
|
||||
Trying to pull ghcr.io/lix-project/lix:latest...
|
||||
|
||||
bash-5.2# nix --version
|
||||
nix (Lix, like Nix) 2.90.0
|
||||
$ docker run -ti nixos/nix
|
||||
Unable to find image 'nixos/nix:latest' locally
|
||||
latest: Pulling from nixos/nix
|
||||
5843afab3874: Pull complete
|
||||
b52bf13f109c: Pull complete
|
||||
1e2415612aa3: Pull complete
|
||||
Digest: sha256:27f6e7f60227e959ee7ece361f75d4844a40e1cc6878b6868fe30140420031ff
|
||||
Status: Downloaded newer image for nixos/nix:latest
|
||||
35ca4ada6e96:/# nix --version
|
||||
nix (Nix) 2.3.12
|
||||
35ca4ada6e96:/# exit
|
||||
```
|
||||
|
||||
# What is included in Lix's Docker image?
|
||||
# What is included in Nix's Docker image?
|
||||
|
||||
The official Docker image is created using [nix2container]
|
||||
The official Docker image is created using `pkgs.dockerTools.buildLayeredImage`
|
||||
(and not with `Dockerfile` as it is usual with Docker images). You can still
|
||||
base your custom Docker image on it as you would do with any other Docker
|
||||
image.
|
||||
|
||||
[nix2container]: https://github.com/nlewo/nix2container
|
||||
The Docker image is also not based on any other image and includes minimal set
|
||||
of runtime dependencies that are required to use Nix:
|
||||
|
||||
The Docker image is also not based on any other image and includes the nixpkgs
|
||||
that Lix was built with along with a minimal set of tools in the system profile:
|
||||
- pkgs.nix
|
||||
- pkgs.bashInteractive
|
||||
- pkgs.coreutils-full
|
||||
- pkgs.gnutar
|
||||
- pkgs.gzip
|
||||
- pkgs.gnugrep
|
||||
- pkgs.which
|
||||
- pkgs.curl
|
||||
- pkgs.less
|
||||
- pkgs.wget
|
||||
- pkgs.man
|
||||
- pkgs.cacert.out
|
||||
- pkgs.findutils
|
||||
|
||||
- bashInteractive
|
||||
- cacert.out
|
||||
- coreutils-full
|
||||
- curl
|
||||
- findutils
|
||||
- gitMinimal
|
||||
- gnugrep
|
||||
- gnutar
|
||||
- gzip
|
||||
- iana-etc
|
||||
- less
|
||||
- libxml2
|
||||
- lix
|
||||
- man
|
||||
- openssh
|
||||
- sqlite
|
||||
- wget
|
||||
- which
|
||||
# Docker image with the latest development version of Nix
|
||||
|
||||
# Docker image with the latest development version of Lix
|
||||
|
||||
FIXME: There are not currently images of development versions of Lix. Tracking issue: https://git.lix.systems/lix-project/lix/issues/381
|
||||
|
||||
You can build a Docker image from source yourself and copy it to either:
|
||||
|
||||
Podman: `nix run '.#dockerImage.copyTo' containers-storage:lix`
|
||||
|
||||
Docker: `nix run '.#dockerImage.copyToDockerDaemon'`
|
||||
|
||||
Then:
|
||||
To get the latest image that was built by [Hydra](https://hydra.nixos.org) run
|
||||
the following command:
|
||||
|
||||
```console
|
||||
$ docker run -ti lix
|
||||
$ curl -L https://hydra.nixos.org/job/nix/master/dockerImage.x86_64-linux/latest/download/1 | docker load
|
||||
$ docker run -ti nix:2.5pre20211105
|
||||
```
|
||||
|
||||
You can also build a Docker image from source yourself:
|
||||
|
||||
```console
|
||||
$ nix build ./\#hydraJobs.dockerImage.x86_64-linux
|
||||
$ docker load -i ./result/image.tar.gz
|
||||
$ docker run -ti nix:2.5pre20211105
|
||||
```
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Installing Lix from Source
|
||||
# Installing Nix from Source
|
||||
|
||||
If no binary package is available or if you want to hack on Lix, you
|
||||
can build Lix from its Git repository.
|
||||
If no binary package is available or if you want to hack on Nix, you
|
||||
can build Nix from its Git repository.
|
||||
|
||||
@@ -1,121 +1,32 @@
|
||||
# Multi-User Mode
|
||||
|
||||
To allow a Nix store to be shared safely among multiple users, it is important that users cannot meaningfully influence the execution of derivation builds such that they could inject malicious code into them without changing their (either input- or output- addressed) hash.
|
||||
If they could do so, they could install a Trojan horse in some package and compromise the accounts of other users.
|
||||
To allow a Nix store to be shared safely among multiple users, it is
|
||||
important that users are not able to run builders that modify the Nix
|
||||
store or database in arbitrary ways, or that interfere with builds
|
||||
started by other users. If they could do so, they could install a Trojan
|
||||
horse in some package and compromise the accounts of other users.
|
||||
|
||||
To prevent this, the Nix store and database are owned by some privileged user (usually `root`) and builders are executed under unprivileged system user accounts (usually named `nixbld1`, `nixbld2`, etc.).
|
||||
When an unprivileged user runs a Nix command, actions that operate on the Nix store (such as builds) are forwarded to a *Nix daemon* running under the owner of the Nix store/database that performs the operation.
|
||||
To prevent this, the Nix store and database are owned by some privileged
|
||||
user (usually `root`) and builders are executed under special user
|
||||
accounts (usually named `nixbld1`, `nixbld2`, etc.). When a unprivileged
|
||||
user runs a Nix command, actions that operate on the Nix store (such as
|
||||
builds) are forwarded to a *Nix daemon* running under the owner of the
|
||||
Nix store/database that performs the operation.
|
||||
|
||||
The buried lede in the above sentence is that *currently*, even in multi-user mode using a daemon, if executing as the user that owns the store, Lix directly manipulates the store unless `--store daemon` is specified.
|
||||
[We intend to change this in the future][multi-user-should-not-be-root].
|
||||
> **Note**
|
||||
>
|
||||
> Multi-user mode has one important limitation: only root and a set of
|
||||
> trusted users specified in `nix.conf` can specify arbitrary binary
|
||||
> caches. So while unprivileged users may install packages from
|
||||
> arbitrary Nix expressions, they may not get pre-built binaries.
|
||||
|
||||
<div class="warning">
|
||||
The Lix team considers the goal of the sandbox to be primarily for preventing reproducibility mistakes, and does not consider multi-user mode to be a strong security boundary between users.
|
||||
|
||||
Do not evaluate or build untrusted, potentially-malicious, Nix language code on machines that you care deeply about maintaining user isolation on.
|
||||
|
||||
Although we would consider any sandbox escapes to be serious security bugs and we intend to fix them, we are not confident enough in the daemon's security to call the daemon a security boundary.
|
||||
</div>
|
||||
|
||||
[multi-user-should-not-be-root]: https://git.lix.systems/lix-project/lix/issues/18
|
||||
|
||||
## Trust model
|
||||
|
||||
There are two categories of users of the Lix daemon: trusted users and untrusted users.
|
||||
The Lix daemon only allows connections from users that are either trusted users, or are specified in, or are members of groups specified in, [`allowed-users`](../command-ref/conf-file.md#conf-allowed-users) in `nix.conf`.
|
||||
Trusted users are users and users of groups specified in [`trusted-users`](../command-ref/conf-file.md#conf-trusted-users) in `nix.conf`.
|
||||
|
||||
All users of the Lix daemon may do the following to bring things into the Nix store:
|
||||
|
||||
- Users may load derivations and output-addressed files into the store with `nix-store --add` or through Nix language code.
|
||||
- Users may locally build derivations, either of the output-addressed or input-addressed variety, creating output paths.
|
||||
|
||||
Note that [fixed-output derivations only consider name and hash](https://github.com/NixOS/nix/issues/969), so it is possible to write a fixed-output derivation for something important with a bogus hash and have it resolve to something else already built in the store.
|
||||
|
||||
On systems with `sandbox` enabled (default on Linux; [not *yet* on macOS][sandbox-enable-macos]), derivations are either:
|
||||
- Input-addressed, so they are run in the sandbox with no network access, with the following exceptions:
|
||||
|
||||
- The (poorly named, since it is not *just* about chroot) property `__noChroot` is set on the derivation and `sandbox` is set to `relaxed`.
|
||||
- On macOS, the derivation property `__darwinAllowLocalNetworking` allows network access to localhost from input-addressed derivations regardless of the `sandbox` setting value. This property exists with such semantics because macOS has no network namespace equivalent to isolate individual processes' localhost networking.
|
||||
- Output-addressed, so they are run with network access but their result must match an expected hash.
|
||||
|
||||
Trusted users may set any setting, including `sandbox = false`, so the sandbox state can be different at runtime from what is described in `nix.conf` for builds invoked with such settings.
|
||||
- Users may copy appropriately-signed derivation outputs into the store.
|
||||
|
||||
By default, any paths *copied into a store* (such as by substitution) must have signatures from [`trusted-public-keys`](../command-ref/conf-file.md#conf-trusted-public-keys) unless they are [output-addressed](../glossary.md#gloss-output-addressed-store-object).
|
||||
|
||||
Unsigned paths may be copied into a store if [`require-sigs`](../command-ref/conf-file.md#conf-require-sigs) is disabled in the daemon's configuration (not default), or if the client is a trusted user and passed `--no-check-sigs` to `nix copy`.
|
||||
- Users may request that the daemon substitutes appropriately-signed derivation outputs from a binary cache in the daemon's [`substituters`](../command-ref/conf-file.md#conf-substituters) list.
|
||||
|
||||
Untrusted clients may also specify additional values for `substituters` (via e.g. `--extra-substituters` on a Nix command) that are listed in [`trusted-substituters`](../command-ref/conf-file.md#conf-trusted-substituters).
|
||||
|
||||
A client could in principle substitute such paths itself then copy them to the daemon (see clause above) if they are appropriately signed but are *not* from a trusted substituter, however this is not implemented in the current Lix client to our knowledge, at the time of writing.
|
||||
This probably means that `trusted-substituters` is a redundant setting except insofar as such substitution would have to be done on the client rather than as root on the daemon; and it is highly defensible to not allow random usage of our HTTP client running as root.
|
||||
|
||||
[sandbox-enable-macos]: https://git.lix.systems/lix-project/lix/issues/386
|
||||
|
||||
### The Lix daemon as a security non-boundary
|
||||
|
||||
The Lix team and wider community does not consider the Lix daemon to be a *security boundary* against malicious Nix language code.
|
||||
|
||||
Although we do our best to make it secure, we do not recommend sharing a Lix daemon with potentially malicious users.
|
||||
That means that public continuous integration (CI) builds of untrusted Nix code should not share builders with CI that writes into a cache used by trusted infrastructure.
|
||||
|
||||
For example, [hydra.nixos.org], which is the builder for [cache.nixos.org], does not execute untrusted Nix language code; a separate system, [ofborg] is used for CI of nixpkgs pull requests.
|
||||
The build output of pull request CI is never pushed to [cache.nixos.org], and those systems are considered entirely untrusted.
|
||||
|
||||
This is because, among other things, the Lix sandbox is *more* susceptible to kernel exploits than Docker, which, unlike Lix, blocks nested user namespaces via `seccomp` in its default policy, and there have been many kernel bugs only exposed to unprivileged users via user namespaces allowing otherwise-root-only system calls.
|
||||
In general, the Lix sandbox is set up to be relatively unrestricted while maintaining its goals of building useful, reproducible software; security is not its primary goal.
|
||||
|
||||
The Lix sandbox is a custom *non-rootless* Linux container implementation that has not been audited to nearly the same degree as Docker and similar systems.
|
||||
Also, the Lix daemon is a complex and historied C++ executable running as root with very little privilege separation.
|
||||
All of this means that a security hole in the Lix daemon gives immediate root access.
|
||||
Systems like Docker (especially non-rootless Docker) should *themselves* probably not be used in a multi-tenant manner with mutually distrusting tenants, but the Lix daemon *especially* should not be used as such as of this writing.
|
||||
|
||||
The primary purpose of the sandbox is to strongly encourage packages to be reproducible, a goal which it is generally quite successful at.
|
||||
|
||||
[hydra.nixos.org]: https://hydra.nixos.org
|
||||
[ofborg]: https://github.com/NixOS/ofborg
|
||||
[cache.nixos.org]: https://cache.nixos.org
|
||||
|
||||
### Trusted users
|
||||
|
||||
Trusted users are permitted to set any setting and bypass security restrictions on the daemon.
|
||||
They are currently in widespread use for a couple of reasons such as remote builds (which we [intend to fix](https://git.lix.systems/lix-project/lix/issues/171)).
|
||||
|
||||
Trusted users are effectively root on Nix daemons running as root (the default configuration) for *at least* the following reasons, and should be thus thought of as equivalent to passwordless sudo.
|
||||
This is not a comprehensive list.
|
||||
|
||||
- They may copy an unsigned malicious built output into the store for `systemd` or anything else that will run as root, then when the system is upgraded, that path will be used from the local store rather than substituted.
|
||||
- They may set the following settings that are commands the daemon will run as root:
|
||||
- `build-hook`
|
||||
- `diff-hook`
|
||||
- `pre-build-hook`
|
||||
- `post-build-hook`
|
||||
- They may set `build-users-group`.
|
||||
|
||||
In particular, they may set it to empty string, which runs builds as root with respect to the rest of the system (!!).
|
||||
We, too, [think that is absurd and intend to not accept such a configuration](https://git.lix.systems/lix-project/lix/issues/242).
|
||||
It is then simply an exercise to the reader to find a daemon that does `SCM_CREDENTIALS` over a `unix(7)` socket and lets you run commands as root, and mount it into the sandbox with `extra-sandbox-paths`.
|
||||
|
||||
At the very least, the Lix daemon itself (since `root` is a trusted user by default) and probably `systemd` qualify for this.
|
||||
- They may set the `builders` list, which will have ssh run as root.
|
||||
We aren't sure if there is a way to abuse this for command execution but it's plausible.
|
||||
|
||||
Note that setting `accept-flake-config` allows arbitrary Nix flakes to set Nix settings in the `nixConfig` stanza.
|
||||
Do not set this setting or pass `--accept-flake-config` while executing untrusted Nix language code as a trusted user for the reasons above!
|
||||
|
||||
## Build users
|
||||
## Setting up the build users
|
||||
|
||||
The *build users* are the special UIDs under which builds are performed.
|
||||
A build user is selected for a build by looking in the group specified by [`build-users-group`](../command-ref/conf-file.md#conf-build-users-group), by default, `nixbld`, then a member of that group not currently executing a build is selected for the build.
|
||||
The build users should not be members of any other group.
|
||||
|
||||
There can never be more concurrent builds than the number of build users, unless using [`auto-allocate-uids`](../command-ref/conf-file.md#conf-auto-allocate-uids) ([tracking issue][auto-allocate-uids-issue]).
|
||||
|
||||
[auto-allocate-uids-issue]: https://git.lix.systems/lix-project/lix/issues/387
|
||||
|
||||
If, for some reason, you need to create such users manually, the following command will create 10 build users on Linux:
|
||||
They should all be members of the *build users group* `nixbld`. This
|
||||
group should have no other members. The build users should not be
|
||||
members of any other group. On Linux, you can create the group and users
|
||||
as follows:
|
||||
|
||||
```console
|
||||
$ groupadd -r nixbld
|
||||
@@ -124,12 +35,43 @@ $ for n in $(seq 1 10); do useradd -c "Nix build user $n" \
|
||||
nixbld$n; done
|
||||
```
|
||||
|
||||
This creates 10 build users. There can never be more concurrent builds
|
||||
than the number of build users, so you may want to increase this if you
|
||||
expect to do many builds at the same time.
|
||||
|
||||
## Running the daemon
|
||||
|
||||
The [Nix daemon](../command-ref/nix-daemon.md) can be started manually as follows (as `root`):
|
||||
The [Nix daemon](../command-ref/nix-daemon.md) should be started as
|
||||
follows (as `root`):
|
||||
|
||||
```console
|
||||
# nix-daemon
|
||||
$ nix-daemon
|
||||
```
|
||||
|
||||
In standard installations of Lix, the daemon is started by a `systemd` unit (Linux) or `launchd` service (macOS).
|
||||
You’ll want to put that line somewhere in your system’s boot scripts.
|
||||
|
||||
To let unprivileged users use the daemon, they should set the
|
||||
[`NIX_REMOTE` environment variable](../command-ref/env-common.md) to
|
||||
`daemon`. So you should put a line like
|
||||
|
||||
```console
|
||||
export NIX_REMOTE=daemon
|
||||
```
|
||||
|
||||
into the users’ login scripts.
|
||||
|
||||
## Restricting access
|
||||
|
||||
To limit which users can perform Nix operations, you can use the
|
||||
permissions on the directory `/nix/var/nix/daemon-socket`. For instance,
|
||||
if you want to restrict the use of Nix to the members of a group called
|
||||
`nix-users`, do
|
||||
|
||||
```console
|
||||
$ chgrp nix-users /nix/var/nix/daemon-socket
|
||||
$ chmod ug=rwx,o= /nix/var/nix/daemon-socket
|
||||
```
|
||||
|
||||
This way, users who are not in the `nix-users` group cannot connect to
|
||||
the Unix domain socket `/nix/var/nix/daemon-socket/socket`, so they
|
||||
cannot perform Nix operations.
|
||||
|
||||
@@ -1,14 +1,15 @@
|
||||
# Security
|
||||
|
||||
Lix has two basic security models. First, it can be used in “single-user
|
||||
Nix has two basic security models. First, it can be used in “single-user
|
||||
mode”, which is similar to what most other package management tools do:
|
||||
there is a single user (typically root) who performs all package
|
||||
management operations. All other users can then use the installed
|
||||
packages, but they cannot perform package management operations
|
||||
themselves.
|
||||
|
||||
Alternatively, you can configure Lix in “multi-user mode”. In this model, all users can perform package management operations — for instance, every user can install software for themselves without requiring root privileges.
|
||||
Lix does its best to ensure that this is secure.
|
||||
For instance, it would be considered a serious security bug for one untrusted user to be able to overwrite a package used by another user with a Trojan horse.
|
||||
|
||||
Nevertheless, the Lix team does not consider multi-user mode a strong security boundary, and does not recommend running untrusted user-supplied Nix language code on privileged machines, even if it is secure to the best of our knowledge at any moment in time.
|
||||
Alternatively, you can configure Nix in “multi-user mode”. In this
|
||||
model, all users can perform package management operations — for
|
||||
instance, every user can install software without requiring root
|
||||
privileges. Nix ensures that this is secure. For instance, it’s not
|
||||
possible for one user to overwrite a package used by another user with a
|
||||
Trojan horse.
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# Obtaining the Source
|
||||
|
||||
The most recent sources of Lix can be obtained from its [Git
|
||||
repository](https://git.lix.systems/lix-project/lix). For example, the following
|
||||
The most recent sources of Nix can be obtained from its [Git
|
||||
repository](https://github.com/NixOS/nix). For example, the following
|
||||
command will check out the latest revision into a directory called
|
||||
`nix`:
|
||||
|
||||
```console
|
||||
$ git clone https://git.lix.systems/lix-project/lix
|
||||
$ git clone https://github.com/NixOS/nix
|
||||
```
|
||||
|
||||
Likewise, specific releases can be obtained from the
|
||||
[tags](https://git.lix.systems/lix-project/lix/tags) of the repository.
|
||||
[tags](https://github.com/NixOS/nix/tags) of the repository.
|
||||
|
||||
@@ -1,15 +1,5 @@
|
||||
# Prerequisites
|
||||
|
||||
<div class="warning">
|
||||
|
||||
FIXME(meson): This section is very wrong with respect to meson and we have commented it out.
|
||||
We are sorry.
|
||||
The most current alternative to this section is to read `package.nix` and see which things are being depended on.
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
|
||||
- GNU Autoconf (<https://www.gnu.org/software/autoconf/>) and the
|
||||
autoconf-archive macro collection
|
||||
(<https://www.gnu.org/software/autoconf-archive/>). These are
|
||||
@@ -68,7 +58,10 @@ The most current alternative to this section is to read `package.nix` and see wh
|
||||
may also work, but ancient versions like the ubiquitous 2.5.4a
|
||||
won't.
|
||||
|
||||
- The `libseccomp` is used to provide syscall filtering on Linux. To get
|
||||
- The `libseccomp` is used to provide syscall filtering on Linux. This
|
||||
is an optional dependency and can be disabled passing a
|
||||
`--disable-seccomp-sandboxing` option to the `configure` script (Not
|
||||
recommended unless your system doesn't support `libseccomp`). To get
|
||||
the library, visit <https://github.com/seccomp/libseccomp>.
|
||||
|
||||
- On 64-bit x86 machines only, `libcpuid` library
|
||||
@@ -83,5 +76,3 @@ The most current alternative to this section is to read `package.nix` and see wh
|
||||
RapidCheck are required, which are available at
|
||||
<https://google.github.io/googletest/> and
|
||||
<https://github.com/emil-e/rapidcheck> respectively.
|
||||
|
||||
-->
|
||||
|
||||
@@ -1,11 +1,7 @@
|
||||
# Supported Platforms
|
||||
|
||||
Lix is currently supported on the following platforms:
|
||||
Nix is currently supported on the following platforms:
|
||||
|
||||
- Linux (i686 (tier 2), x86\_64 (tier 1), aarch64 (tier 1)).
|
||||
- Linux (i686, x86\_64, aarch64).
|
||||
|
||||
- macOS (x86\_64 (tier 2 [(issue to make tier 1)](https://git.lix.systems/lix-project/lix/issues/269)), aarch64 (tier 1)).
|
||||
|
||||
|
||||
Tier 2 platforms aren't checked in CI, so may break without notice; such breakage *is* however considered a bug.
|
||||
We would like for them to work but they are a secondary priority.
|
||||
- macOS (x86\_64, aarch64).
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user