From e30d1daf26bfd4a4647bb8c55c7643f7308e4f88 Mon Sep 17 00:00:00 2001 From: Robert Hensing Date: Wed, 16 Jun 2021 19:06:41 +0200 Subject: [PATCH 01/13] installer: Jeeze -> Oh no Even if it doesn't offend me or probably most people, this word can be considered mildly blasphemous. --- scripts/install-multi-user.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/install-multi-user.sh b/scripts/install-multi-user.sh index e1046c19c..b06847ffe 100644 --- a/scripts/install-multi-user.sh +++ b/scripts/install-multi-user.sh @@ -329,7 +329,7 @@ finish_fail() { finish_cleanup failure < Date: Wed, 20 Jul 2022 14:53:03 +0200 Subject: [PATCH 02/13] nix shell: document how to invoke multiple commands from the command line --- src/nix/shell.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/nix/shell.md b/src/nix/shell.md index 90b81fb2f..161fdeb8d 100644 --- a/src/nix/shell.md +++ b/src/nix/shell.md @@ -23,6 +23,12 @@ R""( Hi everybody! ``` +* Run multiple commands in a shell environment: + + ```console + # nix shell nixpkgs#gnumake -c /bin/sh -c "cd src && make" + ``` + * Run GNU Hello in a chroot store: ```console From 92bae33ca5db60e729ce07156ebf1c06cf865cc8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sol=C3=A8ne=20Rapenne?= Date: Thu, 21 Jul 2022 14:25:07 +0200 Subject: [PATCH 03/13] nix shell: example shouldn't use an absolute path for the shell Co-authored-by: Eelco Dolstra --- src/nix/shell.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/nix/shell.md b/src/nix/shell.md index 161fdeb8d..9fa1031f5 100644 --- a/src/nix/shell.md +++ b/src/nix/shell.md @@ -26,7 +26,7 @@ R""( * Run multiple commands in a shell environment: ```console - # nix shell nixpkgs#gnumake -c /bin/sh -c "cd src && make" + # nix shell nixpkgs#gnumake -c sh -c "cd src && make" ``` * Run GNU Hello in a chroot store: From d8e54d19f71f78540dd967b2e42be6a5d8a0b1bb Mon Sep 17 00:00:00 2001 From: Valentin Gagarin Date: Mon, 22 Aug 2022 12:50:48 +0200 Subject: [PATCH 04/13] Revert "Merge pull request #6420 from nix-community/doc-what-is-nix" This reverts commit 81e101345fda2a8651c470f08b364a1ca6fa37cf, reversing changes made to 7d1280bbaf7f4cd142c2259dec620c42bf6f96fd. --- doc/manual/src/SUMMARY.md.in | 8 - doc/manual/src/architecture/architecture.md | 79 --------- doc/manual/src/architecture/store/fso.md | 69 -------- doc/manual/src/architecture/store/path.md | 105 ------------ doc/manual/src/architecture/store/store.md | 151 ------------------ .../store/store/build-system-terminology.md | 32 ---- .../src/architecture/store/store/closure.md | 29 ---- 7 files changed, 473 deletions(-) delete mode 100644 doc/manual/src/architecture/architecture.md delete mode 100644 doc/manual/src/architecture/store/fso.md delete mode 100644 doc/manual/src/architecture/store/path.md delete mode 100644 doc/manual/src/architecture/store/store.md delete mode 100644 doc/manual/src/architecture/store/store/build-system-terminology.md delete mode 100644 doc/manual/src/architecture/store/store/closure.md diff --git a/doc/manual/src/SUMMARY.md.in b/doc/manual/src/SUMMARY.md.in index 8fbb59716..084c8f442 100644 --- a/doc/manual/src/SUMMARY.md.in +++ b/doc/manual/src/SUMMARY.md.in @@ -59,14 +59,6 @@ @manpages@ - [Files](command-ref/files.md) - [nix.conf](command-ref/conf-file.md) - - [Glossary](glossary.md) - [Contributing](contributing/contributing.md) - [Hacking](contributing/hacking.md) diff --git a/doc/manual/src/architecture/architecture.md b/doc/manual/src/architecture/architecture.md deleted file mode 100644 index 41deb07af..000000000 --- a/doc/manual/src/architecture/architecture.md +++ /dev/null @@ -1,79 +0,0 @@ -# Architecture - -*(This chapter is unstable and a work in progress. Incoming links may rot.)* - -This chapter describes how Nix works. -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 - -Nix consists of [hierarchical layers][layer-architecture]. - -``` -+-----------------------------------------------------------------+ -| Nix | -| [ commmand line interface ]------, | -| | | | -| evaluates | | -| | manages | -| V | | -| [ configuration language ] | | -| | | | -| +-----------------------------|-------------------V-----------+ | -| | store evaluates to | | -| | | | | -| | referenced by V builds | | -| | [ build input ] ---> [ build plan ] ---> [ build result ] | | -| | | | -| +-------------------------------------------------------------+ | -+-----------------------------------------------------------------+ -``` - -At the top is the [command line interface](../command-ref/command-ref.md), translating from invocations of Nix executables to interactions with the underlying layers. - -Below that is the [Nix expression language](../expressions/expression-language.md), a [purely functional][purely-functional-programming] configuration language. -It is used to compose expressions which ultimately evaluate to self-contained *build plans*, used to derive *build results* from referenced *build inputs*. - -The command line and Nix language are what users interact with most. - -> **Note** -> The Nix language itself does not have a notion of *packages* or *configurations*. -> As far as we are concerned here, the inputs and results of a build plan are just data. - -Underlying these is the [Nix store](./store/store.md), a mechanism to keep track of build plans, data, and references between them. -It can also execute build plans to produce new data. - -A build plan is a series of *build tasks*. -Each build task has a special build input which is used as *build instructions*. -The result of a build task can be input to another build task. - -``` -+-----------------------------------------------------------------------------------------+ -| store | -| ................................................. | -| : build plan : | -| : : | -| [ build input ]-----instructions-, : | -| : | : | -| : v : | -| [ build input ]----------->[ build task ]--instructions-, : | -| : | : | -| : | : | -| : v : | -| : [ build task ]----->[ build result ] | -| [ build input ]-----instructions-, ^ : | -| : | | : | -| : v | : | -| [ build input ]----------->[ build task ]---------------' : | -| : ^ : | -| : | : | -| [ build input ]------------------' : | -| : : | -| : : | -| :...............................................: | -| | -+-----------------------------------------------------------------------------------------+ -``` - -[layer-architecture]: https://en.m.wikipedia.org/wiki/Multitier_architecture#Layers -[purely-functional-programming]: https://en.m.wikipedia.org/wiki/Purely_functional_programming diff --git a/doc/manual/src/architecture/store/fso.md b/doc/manual/src/architecture/store/fso.md deleted file mode 100644 index e0eb69f60..000000000 --- a/doc/manual/src/architecture/store/fso.md +++ /dev/null @@ -1,69 +0,0 @@ -# File System Object - -The Nix store uses a simple file system model for the data it holds in [store objects](store.md#store-object). - -Every file system object is one of the following: - - - File: an executable flag, and arbitrary data for contents - - Directory: mapping of names to child file system objects - - [Symbolic link][symlink]: may point anywhere. - -We call a store object's outermost file system object the *root*. - - data FileSystemObject - = File { isExecutable :: Bool, contents :: Bytes } - | Directory { entries :: Map FileName FileSystemObject } - | SymLink { target :: Path } - -Examples: - -- a directory with contents - - /nix/store/-hello-2.10 - ├── bin - │   └── hello - └── share - ├── info - │   └── hello.info - └── man - └── man1 - └── hello.1.gz - -- a directory with relative symlink and other contents - - /nix/store/-go-1.16.9 - ├── bin -> share/go/bin - ├── nix-support/ - └── share/ - -- a directory with absolute symlink - - /nix/store/d3k...-nodejs - └── nix_node -> /nix/store/f20...-nodejs-10.24. - -A bare file or symlink can be a root file system object. -Examples: - - /nix/store/-hello-2.10.tar.gz - - /nix/store/4j5...-pkg-config-wrapper-0.29.2-doc -> /nix/store/i99...-pkg-config-0.29.2-doc - -Symlinks pointing outside of their own root or to a store object without a matching reference are allowed, but might not function as intended. -Examples: - -- an arbitrarily symlinked file may change or not exist at all - - /nix/store/-foo - └── foo -> /home/foo - -- if a symlink to a store path was not automatically created by Nix, it may be invalid or get invalidated when the store object is deleted - - /nix/store/-bar - └── bar -> /nix/store/abc...-foo - -Nix file system objects do not support [hard links][hardlink]: -each file system object which is not the root has exactly one parent and one name. -However, as store objects are immutable, an underlying file system can use hard links for optimization. - -[symlink]: https://en.m.wikipedia.org/wiki/Symbolic_link -[hardlink]: https://en.m.wikipedia.org/wiki/Hard_link diff --git a/doc/manual/src/architecture/store/path.md b/doc/manual/src/architecture/store/path.md deleted file mode 100644 index 663f04f46..000000000 --- a/doc/manual/src/architecture/store/path.md +++ /dev/null @@ -1,105 +0,0 @@ -# Store Path - -Nix implements [references](store.md#reference) to [store objects](store.md#store-object) as *store paths*. - -Store paths are pairs of - -- a 20-byte [digest](#digest) for identification -- a symbolic name for people to read. - -Example: - -- digest: `b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z` -- name: `firefox-33.1` - -It is rendered to a file system path as the concatenation of - - - [store directory](#store-directory) - - path-separator (`/`) - - [digest](#digest) rendered in a custom variant of [base-32](https://en.m.wikipedia.org/wiki/Base32) (20 arbitrary bytes become 32 ASCII characters) - - hyphen (`-`) - - name - -Example: - - /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1 - |--------| |------------------------------| |----------| - store directory digest name - -## Store Directory - -Every [store](./store.md) has a store directory. - -If the store has a [file system representation](./store.md#files-and-processes), this directory contains the store’s [file system objects](#file-system-object), which can be addressed by [store paths](#store-path). - -This means a store path is not just derived from the referenced store object itself, but depends on the store the store object is in. - -> **Note** -> The store directory defaults to `/nix/store`, but is in principle arbitrary. - -It is important which store a given store object belongs to: -Files in the store object can contain store paths, and processes may read these paths. -Nix can only guarantee [referential integrity](store/closure.md) if store paths do not cross store boundaries. - -Therefore one can only copy store objects to a different store if - -- the source and target stores' directories match - - or - -- the store object in question has no references, that is, contains no store paths. - -One cannot copy a store object to a store with a different store directory. -Instead, it has to be rebuilt, together with all its dependencies. -It is in general not enough to replace the store directory string in file contents, as this may render executables unusable by invalidating their internal offsets or checksums. - -# Digest - -In a [store path](#store-path), the [digest][digest] is the output of a [cryptographic hash function][hash] of either all *inputs* involved in building the referenced store object or its actual *contents*. - -Store objects are therefore said to be either [input-addressed](#input-addressing) or [content-addressed](#content-addressing). - -> **Historical Note** -> The 20 byte restriction is because originally digests were [SHA-1][sha-1] hashes. -> Nix now uses [SHA-256][sha-256], and longer hashes are still reduced to 20 bytes for compatibility. - -[digest]: https://en.m.wiktionary.org/wiki/digest#Noun -[hash]: https://en.m.wikipedia.org/wiki/Cryptographic_hash_function -[sha-1]: https://en.m.wikipedia.org/wiki/SHA-1 -[sha-256]: https://en.m.wikipedia.org/wiki/SHA-256 - -### Reference scanning - -When a new store object is built, Nix scans its file contents for store paths to construct its set of references. - -The special format of a store path's [digest](#digest) allows reliably detecting it among arbitrary data. -Nix uses the [closure](store.md#closure) of build inputs to derive the list of allowed store paths, to avoid false positives. - -This way, scanning files captures run time dependencies without the user having to declare them explicitly. -Doing it at build time and persisting references in the store object avoids repeating this time-consuming operation. - -> **Note** -> In practice, it is sometimes still necessary for users to declare certain dependencies explicitly, if they are to be preserved in the build result's closure. -This depends on the specifics of the software to build and run. -> -> For example, Java programs are compressed after compilation, which obfuscates any store paths they may refer to and prevents Nix from automatically detecting them. - -## Input Addressing - -Input addressing means that the digest derives from how the store object was produced, namely its build inputs and build plan. - -To compute the hash of a store object one needs a deterministic serialisation, i.e., a binary string representation which only changes if the store object changes. - -Nix has a custom serialisation format called Nix Archive (NAR) - -Store object references of this sort can *not* be validated from the content of the store object. -Rather, a cryptographic signature has to be used to indicate that someone is vouching for the store object really being produced from a build plan with that digest. - -## Content Addressing - -Content addressing means that the digest derives from the store object's contents, namely its file system objects and references. -If one knows content addressing was used, one can recalculate the reference and thus verify the store object. - -Content addressing is currently only used for the special cases of source files and "fixed-output derivations", where the contents of a store object are known in advance. -Content addressing of build results is still an [experimental feature subject to some restrictions](https://github.com/tweag/rfcs/blob/cas-rfc/rfcs/0062-content-addressed-paths.md). - diff --git a/doc/manual/src/architecture/store/store.md b/doc/manual/src/architecture/store/store.md deleted file mode 100644 index 08b6701d5..000000000 --- a/doc/manual/src/architecture/store/store.md +++ /dev/null @@ -1,151 +0,0 @@ -# Store - -A Nix store is a collection of *store objects* with references between them. -It supports operations to manipulate that collection. - -The following concept map is a graphical outline of this chapter. -Arrows indicate suggested reading order. - -``` - ,--------------[ store ]----------------, - | | | - v v v - [ store object ] [ closure ]--, [ operations ] - | | | | | | - v | | v v | - [ files and processes ] | | [ garbage collection ] | - / \ | | | - v v | v v -[ file system object ] [ store path ] | [ derivation ]--->[ building ] - | ^ | | | - v | v v | - [ digest ]----' [ reference scanning ]<------------' - / \ - v v -[ input addressing ] [ content addressing ] -``` - -## Store Object - -A store object can hold - -- arbitrary *data* -- *references* to other store objects. - -Store objects can be build inputs, build results, or build tasks. - -Store objects are [immutable][immutable-object]: once created, they do not change until they are deleted. - -## Reference - -A store object reference is an [opaque][opaque-data-type], [unique identifier][unique-identifier]: -The only way to obtain references is by adding or building store objects. -A reference will always point to exactly one store object. - -## Operations - -A Nix store can *add*, *retrieve*, and *delete* store objects. - - [ data ] - | - V - [ store ] ---> add ----> [ store' ] - | - V - [ reference ] - - - - [ reference ] - | - V - [ store ] ---> get - | - V - [ store object ] - - - - [ reference ] - | - V - [ store ] --> delete --> [ store' ] - - -It can *perform builds*, that is, create new store objects by transforming build inputs into build outputs, using instructions from the build tasks. - - - [ reference ] - | - V - [ store ] --> build --(maybe)--> [ store' ] - | - V - [ reference ] - - -As it keeps track of references, it can [garbage-collect][garbage-collection] unused store objects. - - - [ store ] --> collect garbage --> [ store' ] - -## Files and Processes - -Nix maps between its store model and the [Unix paradigm][unix-paradigm] of [files and processes][file-descriptor], by encoding immutable store objects and opaque identifiers as file system primitives: files and directories, and paths. -That allows processes to resolve references contained in files and thus access the contents of store objects. - -Store objects are therefore implemented as the pair of - - - a [file system object](fso.md) for data - - a set of [store paths](path.md) for references. - -[unix-paradigm]: https://en.m.wikipedia.org/wiki/Everything_is_a_file -[file-descriptor]: https://en.m.wikipedia.org/wiki/File_descriptor - -The following diagram shows a radical simplification of how Nix interacts with the operating system: -It uses files as build inputs, and build outputs are files again. -On the operating system, files can be run as processes, which in turn operate on files. -A build function also amounts to an operating system process (not depicted). - -``` -+-----------------------------------------------------------------+ -| Nix | -| [ commmand line interface ]------, | -| | | | -| evaluates | | -| | manages | -| V | | -| [ configuration language ] | | -| | | | -| +-----------------------------|-------------------V-----------+ | -| | store evaluates to | | -| | | | | -| | referenced by V builds | | -| | [ build input ] ---> [ build plan ] ---> [ build result ] | | -| | ^ | | | -| +---------|----------------------------------------|----------+ | -+-----------|----------------------------------------|------------+ - | | - file system object store path - | | -+-----------|----------------------------------------|------------+ -| operating system +------------+ | | -| '------------ | | <-----------' | -| | file | | -| ,-- | | <-, | -| | +------------+ | | -| execute as | | read, write, execute | -| | +------------+ | | -| '-> | process | --' | -| +------------+ | -+-----------------------------------------------------------------+ -``` - -There exist different types of stores, which all follow this model. -Examples: -- store on the local file system -- remote store accessible via SSH -- binary cache store accessible via HTTP - -To make store objects accessible to processes, stores ultimately have to expose store objects through the file system. - diff --git a/doc/manual/src/architecture/store/store/build-system-terminology.md b/doc/manual/src/architecture/store/store/build-system-terminology.md deleted file mode 100644 index eefbaa630..000000000 --- a/doc/manual/src/architecture/store/store/build-system-terminology.md +++ /dev/null @@ -1,32 +0,0 @@ -# A [Rosetta stone][rosetta-stone] for build system terminology - -The Nix store's design is comparable to other build systems. -Usage of terms is, for historic reasons, not entirely consistent within the Nix ecosystem, and still subject to slow change. - -The following translation table points out similarities and equivalent terms, to help clarify their meaning and inform consistent use in the future. - -| generic build system | Nix | [Bazel][bazel] | [Build Systems à la Carte][bsalc] | programming language | -| -------------------------------- | ---------------- | -------------------------------------------------------------------- | --------------------------------- | ------------------------ | -| data (build input, build result) | store object | [artifact][bazel-artifact] | value | value | -| build instructions | builder | ([depends on action type][bazel-actions]) | function | function | -| build task | derivation | [action][bazel-action] | `Task` | [thunk][thunk] | -| build plan | derivation graph | [action graph][bazel-action-graph], [build graph][bazel-build-graph] | `Tasks` | [call graph][call-graph] | -| build | build | build | application of `Build` | evaluation | -| persistence layer | store | [action cache][bazel-action-cache] | `Store` | heap | - -All of these systems share features of [declarative programming][declarative-programming] languages, a key insight first put forward by Eelco Dolstra et al. in [Imposing a Memory Management Discipline on Software Deployment][immdsd] (2004), elaborated in his PhD thesis [The Purely Functional Software Deployment Model][phd-thesis] (2006), and further refined by Andrey Mokhov et al. in [Build Systems à la Carte][bsalc] (2018). - -[rosetta-stone]: https://en.m.wikipedia.org/wiki/Rosetta_Stone -[bazel]: https://bazel.build/start/bazel-intro -[bazel-artifact]: https://bazel.build/reference/glossary#artifact -[bazel-actions]: https://docs.bazel.build/versions/main/skylark/lib/actions.html -[bazel-action]: https://bazel.build/reference/glossary#action -[bazel-action-graph]: https://bazel.build/reference/glossary#action-graph -[bazel-build-graph]: https://bazel.build/reference/glossary#build-graph -[bazel-action-cache]: https://bazel.build/reference/glossary#action-cache -[thunk]: https://en.m.wikipedia.org/wiki/Thunk -[call-graph]: https://en.m.wikipedia.org/wiki/Call_graph -[declarative-programming]: https://en.m.wikipedia.org/wiki/Declarative_programming -[immdsd]: https://edolstra.github.io/pubs/immdsd-icse2004-final.pdf -[phd-thesis]: https://edolstra.github.io/pubs/phd-thesis.pdf -[bsalc]: https://www.microsoft.com/en-us/research/uploads/prod/2018/03/build-systems.pdf diff --git a/doc/manual/src/architecture/store/store/closure.md b/doc/manual/src/architecture/store/store/closure.md deleted file mode 100644 index 065b95ffc..000000000 --- a/doc/manual/src/architecture/store/store/closure.md +++ /dev/null @@ -1,29 +0,0 @@ -# Closure - -Nix stores ensure [referential integrity][referential-integrity]: for each store object in the store, all the store objects it references must also be in the store. - -The set of all store objects reachable by following references from a given initial set of store objects is called a *closure*. - -Adding, building, copying and deleting store objects must be done in a way that preserves referential integrity: - -- A newly added store object cannot have references, unless it is a build task. - -- Build results must only refer to store objects in the closure of the build inputs. - - Building a store object will add appropriate references, according to the build task. - -- Store objects being copied must refer to objects already in the destination store. - - Recursive copying must either proceed in dependency order or be atomic. - -- We can only safely delete store objects which are not reachable from any reference still in use. - - - -[referential-integrity]: https://en.m.wikipedia.org/wiki/Referential_integrity -[garbage-collection]: https://en.m.wikipedia.org/wiki/Garbage_collection_(computer_science) -[immutable-object]: https://en.m.wikipedia.org/wiki/Immutable_object -[opaque-data-type]: https://en.m.wikipedia.org/wiki/Opaque_data_type -[unique-identifier]: https://en.m.wikipedia.org/wiki/Unique_identifier - - From a2b7baa42f9e5af5648d1b838aff72f1ad03974c Mon Sep 17 00:00:00 2001 From: Dave Nicponski Date: Wed, 31 Aug 2022 17:25:26 -0400 Subject: [PATCH 05/13] Set `HOME` var to `root`'s home when running `nix-store` as `root` A [recent-ish change](https://github.com/NixOS/nix/pull/6676) logs a warning when a potentially counterintuitive situation happens. This now causes the multi-user installer to [emit a warning](https://github.com/NixOS/nixpkgs/issues/189043) when it's doing the "seed the Nix database" step via a low-level `nix-store --load-db` invocation. `nix-store` functionality implementations don't actually use profiles or channels or homedir as far as i can tell. So why are we hitting this code at all? Well, the current command approach for functionality here builds a [fat `nix` binary](https://github.com/NixOS/nix/blob/master/src/nix/local.mk#L23-L26) which has _all_ the functionality of previous individual binaries (nix-env, nix-store, etc) bundled in, then [uses the invocation name](https://github.com/NixOS/nix/blob/master/src/nix/main.cc#L274-L277) to select the set of commands to expose. `nix` itself has this behavior, even when just trying to parse the (sub)command and arguments: ``` dave @ davembp2 $ nix error: no subcommand specified Try 'nix --help' for more information. dave @ davembp2 $ sudo nix warning: $HOME ('/Users/dave') is not owned by you, falling back to the one defined in the 'passwd' file error: no subcommand specified Try 'nix --help' for more information. dave @ davembp2 $ HOME=~root sudo nix error: no subcommand specified Try 'nix --help' for more information. ``` This behavior can also be seen pretty easily with an arbitrary `nix-store` invocation: ``` dave @ davembp2 $ nix-store --realize dave @ davembp2 $ sudo nix-store --realize # what installer is doing now warning: $HOME ('/Users/dave') is not owned by you, falling back to the one defined in the 'passwd' file dave @ davembp2 $ sudo HOME=~root nix-store --realize # what this PR effectively does dave @ davembp2 $ ``` --- scripts/install-multi-user.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/install-multi-user.sh b/scripts/install-multi-user.sh index 01dbf0c0e..105b84af6 100644 --- a/scripts/install-multi-user.sh +++ b/scripts/install-multi-user.sh @@ -810,7 +810,7 @@ EOF fi _sudo "to load data for the first time in to the Nix Database" \ - "$NIX_INSTALLED_NIX/bin/nix-store" --load-db < ./.reginfo + HOME="$ROOT_HOME" "$NIX_INSTALLED_NIX/bin/nix-store" --load-db < ./.reginfo echo " Just finished getting the nix database ready." ) From bd63ae7e18f649e22ace799e6d366efe4029dc80 Mon Sep 17 00:00:00 2001 From: Matthew Bauer Date: Thu, 1 Sep 2022 23:13:09 -0500 Subject: [PATCH 06/13] =?UTF-8?q?Don=E2=80=99t=20add=20a=20space=20after?= =?UTF-8?q?=20attrs=20completion=20in=20zsh?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This matches the behavior of bash. We don’t want to add a space after completion on attrs. Uses -S. Switches to new compadd style comppletions instead of _describe. Shouldn’t have any negative issues from what I can tell. --- misc/zsh/completion.zsh | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/misc/zsh/completion.zsh b/misc/zsh/completion.zsh index e702c721e..e86984168 100644 --- a/misc/zsh/completion.zsh +++ b/misc/zsh/completion.zsh @@ -10,14 +10,15 @@ function _nix() { local -a suggestions declare -a suggestions for suggestion in ${res:1}; do - # FIXME: This doesn't work properly if the suggestion word contains a `:` - # itself - suggestions+="${suggestion/ /:}" + suggestions+=("${suggestion%% *}") done + local -a args if [[ "$tpe" == filenames ]]; then - compadd -f + args+=('-f') + elif [[ "$tpe" == attrs ]]; then + args+=('-S' '') fi - _describe 'nix' suggestions + compadd -J nix "${args[@]}" -a suggestions } -_nix "$@" +# _nix "$@" From dd3cd1a16740cb20ba00a36f8b3cf8f813e7480f Mon Sep 17 00:00:00 2001 From: Matthew Bauer Date: Fri, 2 Sep 2022 10:50:02 -0500 Subject: [PATCH 07/13] Apply suggestions from code review --- misc/zsh/completion.zsh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/misc/zsh/completion.zsh b/misc/zsh/completion.zsh index e86984168..f9b3dca74 100644 --- a/misc/zsh/completion.zsh +++ b/misc/zsh/completion.zsh @@ -21,4 +21,4 @@ function _nix() { compadd -J nix "${args[@]}" -a suggestions } -# _nix "$@" +_nix "$@" From 4894e567fb27c02866abd75f59da740efa6c33a5 Mon Sep 17 00:00:00 2001 From: Matthew Bauer Date: Fri, 2 Sep 2022 11:46:34 -0500 Subject: [PATCH 08/13] =?UTF-8?q?Don=E2=80=99t=20readDerivation=20if=20imp?= =?UTF-8?q?ure=20derivations=20feature=20is=20disabled?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit readDerivation is pretty slow, and while it may not be significant for some use cases, on things like ghc-nix where we have thousands of derivations is really slows things down. So, this just doesn’t do the impure derivation check if the impure derivation experimental feature is disabled. Perhaps we could cache the result of isPure() and keep the check, but this is a quick fix to for the slowdown introduced with impure derivations features in 2.8.0. --- src/libstore/build/derivation-goal.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libstore/build/derivation-goal.cc b/src/libstore/build/derivation-goal.cc index 83da657f0..41d2e2a1c 100644 --- a/src/libstore/build/derivation-goal.cc +++ b/src/libstore/build/derivation-goal.cc @@ -344,7 +344,7 @@ void DerivationGoal::gaveUpOnSubstitution() for (auto & i : dynamic_cast(drv.get())->inputDrvs) { /* Ensure that pure, non-fixed-output derivations don't depend on impure derivations. */ - if (drv->type().isPure() && !drv->type().isFixed()) { + if (settings.isExperimentalFeatureEnabled(Xp::ImpureDerivations) && drv->type().isPure() && !drv->type().isFixed()) { auto inputDrv = worker.evalStore.readDerivation(i.first); if (!inputDrv.type().isPure()) throw Error("pure derivation '%s' depends on impure derivation '%s'", From 102434e4cbb8ed1b4075f99fb999f092fa068d5b Mon Sep 17 00:00:00 2001 From: Matthew Bauer Date: Sat, 3 Sep 2022 00:27:16 -0500 Subject: [PATCH 09/13] Disable SA_RESTART for some signals on macOS MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Disables the SA_RESTART behavior on macOS which causes: > Restarting of pending calls is requested by setting the SA_RESTART bit > in sa_flags. The affected system calls include read(2), write(2), > sendto(2), recvfrom(2), sendmsg(2) and recvmsg(2) on a communications > channel or a slow device (such as a terminal, but not a regular file) > and during a wait(2) or ioctl(2). From: https://man.openbsd.org/sigaction#SA_RESTART This being set on macOS caused a bug where read() calls to the daemon socket were blocking after a SIGINT was received. As a result, checkInterrupt was never reached even though the signal was received by the signal handler thread. On Linux, SA_RESTART is disabled by default. This probably effects other BSDs but I don’t have the ability to test it there right now. --- src/libmain/shared.cc | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/src/libmain/shared.cc b/src/libmain/shared.cc index 31454e49d..0ee3fe772 100644 --- a/src/libmain/shared.cc +++ b/src/libmain/shared.cc @@ -194,9 +194,16 @@ void initNix() /* HACK: on darwin, we need can’t use sigprocmask with SIGWINCH. * Instead, add a dummy sigaction handler, and signalHandlerThread * can handle the rest. */ - struct sigaction sa; - sa.sa_handler = sigHandler; - if (sigaction(SIGWINCH, &sa, 0)) throw SysError("handling SIGWINCH"); + act.sa_handler = sigHandler; + if (sigaction(SIGWINCH, &act, 0)) throw SysError("handling SIGWINCH"); + + // Disable SA_RESTART for interrupts, so that system calls on this thread + // error with EINTR like they do on Linux, and we don’t hang forever. + act.sa_handler = SIG_DFL; + if (sigaction(SIGINT, &act, 0)) throw SysError("handling SIGINT"); + if (sigaction(SIGTERM, &act, 0)) throw SysError("handling SIGTERM"); + if (sigaction(SIGHUP, &act, 0)) throw SysError("handling SIGHUP"); + if (sigaction(SIGPIPE, &act, 0)) throw SysError("handling SIGPIPE"); #endif /* Register a SIGSEGV handler to detect stack overflows. */ From a47b5476e1efb5c571f5a032a0b63ac8a2dfae82 Mon Sep 17 00:00:00 2001 From: Matthew Bauer Date: Sat, 3 Sep 2022 16:06:33 -0500 Subject: [PATCH 10/13] Add more signals --- src/libmain/shared.cc | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/src/libmain/shared.cc b/src/libmain/shared.cc index 0ee3fe772..9769c993e 100644 --- a/src/libmain/shared.cc +++ b/src/libmain/shared.cc @@ -181,8 +181,9 @@ void initNix() /* Reset SIGCHLD to its default. */ struct sigaction act; sigemptyset(&act.sa_mask); - act.sa_handler = SIG_DFL; act.sa_flags = 0; + + act.sa_handler = SIG_DFL; if (sigaction(SIGCHLD, &act, 0)) throw SysError("resetting SIGCHLD"); @@ -197,13 +198,23 @@ void initNix() act.sa_handler = sigHandler; if (sigaction(SIGWINCH, &act, 0)) throw SysError("handling SIGWINCH"); - // Disable SA_RESTART for interrupts, so that system calls on this thread - // error with EINTR like they do on Linux, and we don’t hang forever. + /* Disable SA_RESTART for interrupts, so that system calls on this thread + * error with EINTR like they do on Linux. + * Most signals on BSD systems default to SA_RESTART on, but Nix + * expects EINTR from syscalls to properly exit. */ act.sa_handler = SIG_DFL; if (sigaction(SIGINT, &act, 0)) throw SysError("handling SIGINT"); if (sigaction(SIGTERM, &act, 0)) throw SysError("handling SIGTERM"); if (sigaction(SIGHUP, &act, 0)) throw SysError("handling SIGHUP"); if (sigaction(SIGPIPE, &act, 0)) throw SysError("handling SIGPIPE"); + if (sigaction(SIGQUIT, &act, 0)) throw SysError("handling SIGQUIT"); + if (sigaction(SIGILL, &act, 0)) throw SysError("handling SIGILL"); + if (sigaction(SIGTRAP, &act, 0)) throw SysError("handling SIGTRAP"); + if (sigaction(SIGABRT, &act, 0)) throw SysError("handling SIGABRT"); + if (sigaction(SIGFPE, &act, 0)) throw SysError("handling SIGFPE"); + if (sigaction(SIGBUS, &act, 0)) throw SysError("handling SIGBUS"); + if (sigaction(SIGXCPU, &act, 0)) throw SysError("handling SIGXCPU"); + if (sigaction(SIGXFSZ, &act, 0)) throw SysError("handling SIGXFSZ"); #endif /* Register a SIGSEGV handler to detect stack overflows. */ From 3fca5f6c693179a2b49add54166b1a126c755264 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Th=C3=A9ophane=20Hufschmitt?= Date: Mon, 5 Sep 2022 14:44:01 +0200 Subject: [PATCH 11/13] Installer: Reset the timestamps in the tarball Otherwise it isn't reproducible. Fix https://github.com/NixOS/nix/issues/7001 --- flake.nix | 1 + 1 file changed, 1 insertion(+) diff --git a/flake.nix b/flake.nix index 1b26460e7..cdb81179a 100644 --- a/flake.nix +++ b/flake.nix @@ -260,6 +260,7 @@ echo "file binary-dist $fn" >> $out/nix-support/hydra-build-products tar cvfJ $fn \ --owner=0 --group=0 --mode=u+rw,uga+r \ + --mtime='1970-01-01' \ --absolute-names \ --hard-dereference \ --transform "s,$TMPDIR/install,$dir/install," \ From 77d3d3d18d181f4abe63d48361a96f4aac30668d Mon Sep 17 00:00:00 2001 From: Matthew Bauer Date: Tue, 6 Sep 2022 09:47:53 -0500 Subject: [PATCH 12/13] Remove some signals --- src/libmain/shared.cc | 6 ------ 1 file changed, 6 deletions(-) diff --git a/src/libmain/shared.cc b/src/libmain/shared.cc index 9769c993e..52b75f757 100644 --- a/src/libmain/shared.cc +++ b/src/libmain/shared.cc @@ -208,13 +208,7 @@ void initNix() if (sigaction(SIGHUP, &act, 0)) throw SysError("handling SIGHUP"); if (sigaction(SIGPIPE, &act, 0)) throw SysError("handling SIGPIPE"); if (sigaction(SIGQUIT, &act, 0)) throw SysError("handling SIGQUIT"); - if (sigaction(SIGILL, &act, 0)) throw SysError("handling SIGILL"); if (sigaction(SIGTRAP, &act, 0)) throw SysError("handling SIGTRAP"); - if (sigaction(SIGABRT, &act, 0)) throw SysError("handling SIGABRT"); - if (sigaction(SIGFPE, &act, 0)) throw SysError("handling SIGFPE"); - if (sigaction(SIGBUS, &act, 0)) throw SysError("handling SIGBUS"); - if (sigaction(SIGXCPU, &act, 0)) throw SysError("handling SIGXCPU"); - if (sigaction(SIGXFSZ, &act, 0)) throw SysError("handling SIGXFSZ"); #endif /* Register a SIGSEGV handler to detect stack overflows. */ From 6ce2e96c88c71e40303980eb5793aa6ae4a5a333 Mon Sep 17 00:00:00 2001 From: Jonathan Ringer Date: Tue, 6 Sep 2022 08:18:13 -0700 Subject: [PATCH 13/13] Docs: Add nix develop --command entry Add example of nix develop being used to execuate a series of script commands. This is common when doing things like CI/CD, and should be represented in the official documentation. Also useful for people looking for the 'nix develop' equivalent of 'nix-shell --run'. Related: - https://github.com/NixOS/nix/issues/6908 - https://github.com/NixOS/nix/issues/6908#issuecomment-1229266853 --- src/nix/develop.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/nix/develop.md b/src/nix/develop.md index e036ec6b9..4e8542d1b 100644 --- a/src/nix/develop.md +++ b/src/nix/develop.md @@ -66,6 +66,12 @@ R""( `nixpkgs#glibc` in `~/my-glibc` and want to compile another package against it. +* Run a series of script commands: + + ```console + # nix develop --command bash -c "mkdir build && cmake .. && make" + ``` + # Description `nix develop` starts a `bash` shell that provides an interactive build