From 0f2dee444b590099d23ecfcb2f74e86042546a4f Mon Sep 17 00:00:00 2001 From: figsoda Date: Tue, 10 Feb 2026 14:45:43 -0500 Subject: [PATCH] Fix typos --- README.md | 2 +- rfcs/0001-rfc-process.md | 8 ++--- rfcs/0023-musl-libc.md | 8 ++--- rfcs/0026-staging-workflow.md | 6 ++-- rfcs/0036-rfc-process-team-amendment.md | 4 +-- rfcs/0039-unprivileged-maintainer-teams.md | 2 +- rfcs/0042-config-option.md | 2 +- rfcs/0044-disband-nix-core.md | 4 +-- rfcs/0062-content-addressed-paths.md | 30 +++++++++---------- ...md => 0085-nixos-release-stabilization.md} | 4 +-- rfcs/0092-plan-dynamism.md | 4 +-- rfcs/0119-testing-conventions.md | 2 +- rfcs/0127-issues-warnings.md | 4 +-- rfcs/0130-stalled-rfcs.md | 4 +-- rfcs/0133-git-hashing.md | 2 +- rfcs/0136-stabilize-incrementally.md | 8 ++--- rfcs/0140-simple-package-paths.md | 4 +-- rfcs/0146-meta-categories.md | 4 +-- 18 files changed, 51 insertions(+), 51 deletions(-) rename rfcs/{0085-nixos-release-stablization.md => 0085-nixos-release-stabilization.md} (98%) diff --git a/README.md b/README.md index 65cf7a6d0..ddaf9ce64 100644 --- a/README.md +++ b/README.md @@ -101,7 +101,7 @@ graph TD NoShepherds[Closed - Lack of Interest]:::closed NoShepherds --> |Renewed Interest| Discuss - FCP[Final Coment Phase] + FCP[Final Comment Phase] FCP --> |FCP Canceled| Discuss FCP --> |Accept| Merged FCP --> |Reject| Rejected diff --git a/rfcs/0001-rfc-process.md b/rfcs/0001-rfc-process.md index c554bd76b..a414dfdcf 100644 --- a/rfcs/0001-rfc-process.md +++ b/rfcs/0001-rfc-process.md @@ -23,7 +23,7 @@ because they introduce new concepts, big changes or are controversial enough that not everybody will agree on the direction to take. Therefore, the purpose of this RFC is to introduce a process that allows to -bring the discussion upfront and avoid unnecesary implementations. It forces +bring the discussion upfront and avoid unnecessary implementations. It forces developers to formulate their ideas without getting bogged down into implementation details. This RFC is used to bootstrap the process and further RFCs can be used to refine the process. @@ -64,7 +64,7 @@ Pull requests that contain any of the afore mentioned 'substantial' changes may ## Description of the process In short, to get a major feature added to the Nix ecosystem, one should first -go through the RFC process in order to improve the likelyhood of inclusion. +go through the RFC process in order to improve the likelihood of inclusion. Here are roughly the steps that one would take: * Fork the RFC repo https://github.com/NixOS/rfcs @@ -79,12 +79,12 @@ that will help them bring the RFC to completion. The goal is to improve the chances that the RFC is both desired and likely to be implemented. Once the author is happy with the state of the RFC, they should seek for -wider community review by stating the readyness of the work. Advertisement on +wider community review by stating the readiness of the work. Advertisement on the mailing-list and IRC is an acceptable way of doing that. After a number of rounds of review the discussion should settle and a general consensus should emerge. This bit is left intentionally vague and should be -refined in the future. We don't have a technical commitee so controversial +refined in the future. We don't have a technical committee so controversial changes will be rejected by default. If a RFC is accepted then authors may implement it and submit the feature as a diff --git a/rfcs/0023-musl-libc.md b/rfcs/0023-musl-libc.md index f20ea16b0..5e88f3b70 100644 --- a/rfcs/0023-musl-libc.md +++ b/rfcs/0023-musl-libc.md @@ -66,7 +66,7 @@ most popular libc implementation on Linux, and is used by a number of important projects you may be familiar with large userbases, including: * Alpine Linux - [#70 on Distrowatch](https://distrowatch.com/table.php?distribution=alpine) but very popular amongst docker users for producing slim container images. -* [OpenWRT/LEDE](https://openwrt.org/) - #1 open-source Linux router firmware project; foundation of most other projects targetting routers. +* [OpenWRT/LEDE](https://openwrt.org/) - #1 open-source Linux router firmware project; foundation of most other projects targeting routers. More projects and details of how they use musl can be found here: https://wiki.musl-libc.org/projects-using-musl.html @@ -86,7 +86,7 @@ The main arguments for inclusion are: * Software sometimes must be patched to compile or run with musl; in @dtzWill's experience, these changes are largely fixes improving compliance and correctness resulting in higher-quality programs. Recent versions of glibc have started taking stronger stances - on enforcing compliance (look at patch fallout folllowing any glibc upgrade in last year or so) + on enforcing compliance (look at patch fallout following any glibc upgrade in last year or so) resulting in overlapping work from both sides. (NOTE: use of glibc extensions or reliance on non-standard behavior is still common and unlikely to go away soon) @@ -107,7 +107,7 @@ do folks believe the costs are too high? * [projects using musl](https://wiki.musl-libc.org/projects-using-musl.html) * [Slides from a talk discussing various libcs, 2014](http://events17.linuxfoundation.org/sites/events/files/slides/libc-talk.pdf) -## Related Isssues +## Related Issues * [big musl PR](https://github.com/NixOS/nixpkgs/pull/34645) * [issues matching "musl", newest first](https://github.com/NixOS/nixpkgs/search?o=desc&q=musl&s=created&type=Issues&utf8=%E2%9C%93) @@ -212,7 +212,7 @@ Unfortunately this is unrealistic due to capacity constraints and other reasons. ### Responsibility -"musl team" is reponsible, initially consisting of +"musl team" is responsible, initially consisting of * @dtzWill * @shlevy diff --git a/rfcs/0026-staging-workflow.md b/rfcs/0026-staging-workflow.md index d4b336c81..c39262b29 100644 --- a/rfcs/0026-staging-workflow.md +++ b/rfcs/0026-staging-workflow.md @@ -9,7 +9,7 @@ related-issues: # Summary [summary]: #summary -Define a new workflow for the `staging` branch that can better accomodate the +Define a new workflow for the `staging` branch that can better accommodate the current and future influx of changes in order to deliver mass-rebuilds faster to master. As part of this new workflow an additional branch, `staging-next`, shall be introduced. @@ -20,14 +20,14 @@ be introduced. The current workflow cannot handle the high amount of mass-rebuilds that are continuously delivered, resulting in long delays for these deliveries to reach -`master`. When a certain delivery causes failures, attemps are typically made to +`master`. When a certain delivery causes failures, attempts are typically made to fix these failures and stabilize `staging` so that the specific delivery can still reach `master`. Often it happens that during this period of stabilization other mass-rebuilds are submitted, and it is not uncommon that these also introduce failures, thus again increasing the time it takes for a delivery to reach `master`. This is -especially worrysome in case of security fixes that need to be delivered as soon +especially worrisome in case of security fixes that need to be delivered as soon as possible. # Detailed design diff --git a/rfcs/0036-rfc-process-team-amendment.md b/rfcs/0036-rfc-process-team-amendment.md index 896219b30..c76fcf44f 100644 --- a/rfcs/0036-rfc-process-team-amendment.md +++ b/rfcs/0036-rfc-process-team-amendment.md @@ -60,7 +60,7 @@ This team should be people who are very familiar with the main components touched by the RFC. The author cannot be part of the Shepherd Team. In addition, at most half of the Shepherd Team can be part of the RFC Steering Committee. -The resposibility of the team is to guide the discussion as long as it is +The responsibility of the team is to guide the discussion as long as it is constructive, new points are brought up and the RFC is iterated on and from time to time summarise the current state of discussion. If this is the case no longer, then the Shepherd Team shall step in with a motion for FCP. @@ -68,7 +68,7 @@ then the Shepherd Team shall step in with a motion for FCP. ##### Shepherd Leader The person in charge of the RFC process for a specific RFC, and responsible for ensuring the process is followed in a timely fashion. The Shepherd Leader has no -special resposibility with regard to moving an undecided Shepherd Team to a +special responsibility with regard to moving an undecided Shepherd Team to a certain decision. ##### Final Comment Period (FCP) diff --git a/rfcs/0039-unprivileged-maintainer-teams.md b/rfcs/0039-unprivileged-maintainer-teams.md index bcdbb82cc..16e945193 100644 --- a/rfcs/0039-unprivileged-maintainer-teams.md +++ b/rfcs/0039-unprivileged-maintainer-teams.md @@ -178,7 +178,7 @@ for requested reviews](https://github.com/pulls/review-requested). automation with credentials on an automated basis. # Future Potential RFCs -The following topics are explictly _not_ part of this RFC. +The following topics are explicitly _not_ part of this RFC. - Allowing maintainers to merge pull requests against their packages without having commit access. diff --git a/rfcs/0042-config-option.md b/rfcs/0042-config-option.md index ecefdcd68..294c490f3 100644 --- a/rfcs/0042-config-option.md +++ b/rfcs/0042-config-option.md @@ -192,7 +192,7 @@ The second part of this RFC aims to encourage people to write better NixOS modul This RFC has to be thought of as a basis for *new* modules first and foremost. By using this approach we can provide a good basis for new modules, with great flexibility for future changes. -For existing modules, it is often not possible to use this `settings` style without breaking backwards compatibility. How this is handled is left up to the module authors. A workaround that could be employed is to define options `useLegacyConfig` or `declarative` which determin the modules behavior in regards to old options. +For existing modules, it is often not possible to use this `settings` style without breaking backwards compatibility. How this is handled is left up to the module authors. A workaround that could be employed is to define options `useLegacyConfig` or `declarative` which determine the modules behavior in regards to old options. # Drawbacks [drawbacks]: #drawbacks diff --git a/rfcs/0044-disband-nix-core.md b/rfcs/0044-disband-nix-core.md index be2700b83..130595b6c 100644 --- a/rfcs/0044-disband-nix-core.md +++ b/rfcs/0044-disband-nix-core.md @@ -20,7 +20,7 @@ evolution of the Nix ecosystem and community. It was originally slated as a year-long experiment. It is now a little over a year since officially merging. In that time, -the core team has not made signifcant progress on its initial goals. +the core team has not made significant progress on its initial goals. We now have the RFC steering/shepherding process which serves similar goals (but for the whole ecosystem, not just Nix proper) and is operating well. The remaining functions of the core team *not* covered @@ -46,7 +46,7 @@ announce on all relevant forums. * Keep the core team around in its current form and responsibilities. Would require a fresh attempt to follow through on the relevant - committments to be practical. + commitments to be practical. * Reform the core team based on what we've learned, including possibly narrowing the scope. diff --git a/rfcs/0062-content-addressed-paths.md b/rfcs/0062-content-addressed-paths.md index 742b02d26..19ac4544d 100644 --- a/rfcs/0062-content-addressed-paths.md +++ b/rfcs/0062-content-addressed-paths.md @@ -1,5 +1,5 @@ --- -feature: Simple content-adressed store paths +feature: Simple content-addressed store paths start-date: 2019-08-14 author: Théophane Hufschmitt co-authors: (find a buddy later to help our with the RFC) @@ -15,7 +15,7 @@ related-issues: (will contain links to implementation PRs) Add some experimental support for content-addressed store paths to Nix. We plan here to give the possibility to mark certain store paths as -content-adressed (ca), while keeping the other input-adressed as they are +content-addressed (ca), while keeping the other input-addressed as they are now (modulo some mandatory drv rewriting before the build, see below). By making this opt-in, we can impose arbitrary limitations to the paths that @@ -37,7 +37,7 @@ the `ca-derivation` experimental flag. [motivation]: #motivation -Having a content-adressed store with Nix (aka the "Intensional store") is a +Having a content-addressed store with Nix (aka the "Intensional store") is a long-time dream of the community − a design for that was already taking a whole chapter in [Eelco's PHD thesis][nixphd]. @@ -45,9 +45,9 @@ This was never done because it represents quite a big change in Nix's model, with some non-trivial implications (regarding the trust model in particular). Even without going all the way down to a fully intensional model, we can -make specific paths content-adressed, which can give some important benefits of +make specific paths content-addressed, which can give some important benefits of the intensional store at a much lower price. In particular, setting some -critical derivations as content-adressed can lead to some substantial build +critical derivations as content-addressed can lead to some substantial build cutoffs. # Detailed design @@ -87,7 +87,7 @@ these derivations). To fully support this content-addressed model, we need to extend the current build process, as well as the caching and remote building systems so that they -are able to take into account the specificies of these new derivations. +are able to take into account the specifics of these new derivations. Fully supporting content-addressed derivations requires some deep changes to the Nix model. For the sake of readability, we’ll first present a simplistic model that support them in a very basic way, and then extend this model in several different ways to improve the support. @@ -119,7 +119,7 @@ the output paths of a derivation before building it. This means that the Nix evaluator doesn’t know the output paths of the dependencies it manipulates (it _could_ know them if they are already built, but that would be a blatant purity hole), so these derivations can’t neither embed -their own output path, nor explicitely refer to their dependencies by their +their own output path, nor explicitly refer to their dependencies by their output path. ### Output mappings @@ -214,7 +214,7 @@ A store path `/nix/store/abc-foo` is said to be **self-referential** if the content of the path mentions the path `/nix/store/abc-foo` itself (and this mention of the store path is called a **self-reference**). -A lot of store paths happen to be self-referential (for example a path that contains both an dynamic library and an executable using that library will likely have the `rpath` of the exectuable mention the absolute path to the library). +A lot of store paths happen to be self-referential (for example a path that contains both an dynamic library and an executable using that library will likely have the `rpath` of the executable mention the absolute path to the library). It happens that these are problematic with content-addressed derivations, because @@ -224,9 +224,9 @@ It happens that these are problematic with content-addressed derivations, becaus However, under the assumption that self-references only appear textually in the output (_i.e_ running strings on a file that contains self-references will print all the self-references out), we can: - Build the derivation on a temporary directory (`/nix/store/someArbitraryHash-foo`, the path provided by the function `assignScratchOutputPaths` above) -- Replace all the occurences of `someArbitraryHash` by a fixed magic value +- Replace all the occurrences of `someArbitraryHash` by a fixed magic value - Compute the hash of the resulting path to determine the final path -- Replace the occurences of the magic value by the final path hash +- Replace the occurrences of the magic value by the final path hash - Move the result to the final path. This is obviously a hack, however it seems to work very well in practice, due to the fact that: @@ -311,7 +311,7 @@ work on store paths, but rather at the realisation level: If the store knows about the given derivation output, it will return the associated realisation, otherwise it will return `None`. -- The substitution loop in Nix fist calls this method to ask the remote for the +- The substitution loop in Nix first calls this method to ask the remote for the realisation of the current derivation output. If this first call succeeds, then it fetches the corresponding output path like before. Then, it registers the realisation in the database: @@ -330,7 +330,7 @@ This folder contains a set of files of the form `{drvOutput}.doi`, each of them #### The “two-glibc” issue -As stated in [Eelco’s thesis][nixphd], remote caching of content-addressed derivations can be problematic in conjonction with non-determinism: +As stated in [Eelco’s thesis][nixphd], remote caching of content-addressed derivations can be problematic in conjunction with non-determinism: A typical scenario where this can happen is: @@ -431,8 +431,8 @@ We also update `registerRealisation` for the local store to check these signatur same end-goal. The big difference between these two is in the scope they cover: RFC 0017 is about fundamentally changing the base model of Nix, while this proposal suggests to make only the minimal amount of changes to the current -model to allow the content-adressed model to live in parallel (which would open -the way to a fully content-adressed store as RFC0017, but in a much more +model to allow the content-addressed model to live in parallel (which would open +the way to a fully content-addressed store as RFC0017, but in a much more incremental way). Eventually this RFC should be subsumed by RFC0017. @@ -485,7 +485,7 @@ annoying since: - More annoyingly, these references become dangling and can cause runtime failures -We however have a way to dectect these: If we have leaking self-references then +We however have a way to detect these: If we have leaking self-references then the output will change if we artificially change its output path. This could be integrated in the `--check` option of `nix-store`. diff --git a/rfcs/0085-nixos-release-stablization.md b/rfcs/0085-nixos-release-stabilization.md similarity index 98% rename from rfcs/0085-nixos-release-stablization.md rename to rfcs/0085-nixos-release-stabilization.md index d07528435..b8cb9b5fd 100644 --- a/rfcs/0085-nixos-release-stablization.md +++ b/rfcs/0085-nixos-release-stabilization.md @@ -1,5 +1,5 @@ --- -feature: nixos-release-stablization +feature: nixos-release-stabilization start-date: 2021-01-17 author: Jonathan Ringer (@jonringer) co-authors: @@ -13,7 +13,7 @@ related-issues: "[NixOS release schedule](https://github.com/NixOS/rfcs/pull/80) To bring more certainty to the release cycle, add short periods where breaking changes are partially restricted. A list of Release Critical -Packages is defined. Also, move most release stablization work from +Packages is defined. Also, move most release stabilization work from the `release` branch to the `master` branch to reduce backports. # Motivation diff --git a/rfcs/0092-plan-dynamism.md b/rfcs/0092-plan-dynamism.md index 6197e1101..333a43abf 100644 --- a/rfcs/0092-plan-dynamism.md +++ b/rfcs/0092-plan-dynamism.md @@ -69,7 +69,7 @@ It's very efficient, because it doesn't obligate the use of the Nix expression l It's also quite compatible with `--dry-run`. Because derivations don't get new dependencies *mid build*, we have no need to mess with individual steps to explore the plan. -There still becomes multiple sorts of `--dry-run` policies, but all of them just have to do with building or not buidling derivations which *themselves* are unchanged. +There still becomes multiple sorts of `--dry-run` policies, but all of them just have to do with building or not building derivations which *themselves* are unchanged. To make that more, clear, if you *do* want one big ("hundreds of thousands of nodes"-big), static graph, you can still have it! Build all the derivations that compute derivations, but not nothing else. @@ -222,7 +222,7 @@ gives us the path to an output of it. still can not build derivations and then use them at evaluation time, meaning that you can't have an attribute set whose contents are determined by some build, and then access that attribute set - outside of build that dependens on that derivation. + outside of build that depends on that derivation. - We unfortunately expose the `text` `outputHashMode` to users. Preferably this should be removed entirely, in addition to `flat`, and everything should just use `recursive`. diff --git a/rfcs/0119-testing-conventions.md b/rfcs/0119-testing-conventions.md index 3236f9a1f..ac73f4cfe 100644 --- a/rfcs/0119-testing-conventions.md +++ b/rfcs/0119-testing-conventions.md @@ -57,7 +57,7 @@ as this will help define what breakages a pull request author should take owners - E.g. `nixos-test` `kvm` `big-parallel` Usage for mkDerivation's `checkPhase`: -- Quick "cheap" tests, which run units tests and maybe some addtional scenarios. +- Quick "cheap" tests, which run units tests and maybe some additional scenarios. - Since this contributes to the "build time" of a package, there should be some emphasis on ensuring this phase isn't bloated. diff --git a/rfcs/0127-issues-warnings.md b/rfcs/0127-issues-warnings.md index 18e365e0b..c1abc862e 100644 --- a/rfcs/0127-issues-warnings.md +++ b/rfcs/0127-issues-warnings.md @@ -147,7 +147,7 @@ When a package has a problem that `error`s, all packages that depend on it will When the problem requires actions on dependents however, it does not sufficiently inform about all packages that need action. Multiple packages may be annotated with the same problem, in that case it should be given a name and the name should be the same across all instances. Other values like the message or the URL list do not need to be the same and may be adapted sensibly. -### Backwards compatbility, Backporting and stable releases +### Backwards compatibility, Backporting and stable releases New problems generally should not be added to stable branches if possible, and also not be backported to them, since it may break evaluation. The same rule applies to other changes to a package or its `meta` which may generate a problem and thus lead to evaluation failure too. Scenarios where evaluation failure is a desired goal, for example with unfixable security issues, are obviously exempt from this. @@ -272,7 +272,7 @@ These have the advantage of enforcing the presence of a name if there are multip On the nixpkgs configuration side, the first iteration used a generic "predicate" system for ignoring packages, similar to `allowUnfreePredicate` and `allowInsecurePredicate`. This turned out to be both too flexible and not convenient enough to use, so this was complemented with a list of packages to ignore and "smart" default values generation. -A second approach used a list type: `list of ("packageName.warningKind" or "packageName.*" or "*.warningKind" or "*.*")`. This was a binary choice (compared to the ternary value today), with an additional boolean `traceIgnoredWarnings` option. One downside is that it does not allow granular control over warnings, only evaluation failures. A bigger issue is that due to how the merge rules on lists work, it would have been difficult to provide good default values for the nixpkgs confinguration while keeping backwards compatibility. +A second approach used a list type: `list of ("packageName.warningKind" or "packageName.*" or "*.warningKind" or "*.*")`. This was a binary choice (compared to the ternary value today), with an additional boolean `traceIgnoredWarnings` option. One downside is that it does not allow granular control over warnings, only evaluation failures. A bigger issue is that due to how the merge rules on lists work, it would have been difficult to provide good default values for the nixpkgs configuration while keeping backwards compatibility. A third approach used a two-level attribute set, similarly to the list above, but with the value setting the handler instead of it being a binary choice. `"*"."*" = "error";`, `myPackage."*" = "ignore";`, `"*".maintainerless = "ignore";`, etc. This provides better merging behavior than a list, while also being more granular. However, people voiced concerns about people accidentally wildcard-ignoring everything. Also, it is ambiguous on matching problem name vs problem kind, which mostly works fine but might lead to weird things happening in the case where new kinds are introduced. diff --git a/rfcs/0130-stalled-rfcs.md b/rfcs/0130-stalled-rfcs.md index 9c0e901c4..f640351c1 100644 --- a/rfcs/0130-stalled-rfcs.md +++ b/rfcs/0130-stalled-rfcs.md @@ -47,7 +47,7 @@ graph TD NoShepherds[Closed - Lack of Interest]:::closed NoShepherds --> |Renewed Interest| Discuss - FCP[Final Coment Phase] + FCP[Final Comment Phase] FCP --> |FCP Canceled| Discuss FCP --> |Accept| Merged FCP --> |Reject| Rejected @@ -144,4 +144,4 @@ None # Future work [future]: #future-work -The ony work that needs to be done is updating documentation and informing the NixOS RFC Steering Committee. +The only work that needs to be done is updating documentation and informing the NixOS RFC Steering Committee. diff --git a/rfcs/0133-git-hashing.md b/rfcs/0133-git-hashing.md index 81eb9f192..d712f7dc0 100644 --- a/rfcs/0133-git-hashing.md +++ b/rfcs/0133-git-hashing.md @@ -64,7 +64,7 @@ This support entails two basic things: Git hashing would not (in this first proposed version) support references, since references in Nix's sense are not part of Git's data model. This is OK for now; encoding references is not needed for the intended initial use-case of exchanging source code. -## Git file hashing for `buitins.fetch*` +## Git file hashing for `builtins.fetch*` - **Purpose**: Source distribution and archival - **Depends on**: Git file hashing diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 948b4ea92..2c182fd46 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -157,9 +157,9 @@ These basic layering principles will be added to the [Nix architecture documenta Features should be in the lowest layer it makes sense to have them. -## The general stabilization process --- audit, refine, and *then* stabilze +## The general stabilization process --- audit, refine, and *then* stabilize -See the [current documentation on experimental features and their lifecyle](https://nixos.org/manual/nix/stable/contributing/experimental-features.html). +See the [current documentation on experimental features and their lifecycle](https://nixos.org/manual/nix/stable/contributing/experimental-features.html). Stabilization of any feature, not just the CLI or Flakes, is not a matter of just flipping a switch on an implementation that has accrued for a period of time. Because the moment before stabilization is our last chance to make major changes, it is crucial that we look over what is being stabilized. @@ -181,7 +181,7 @@ To stabilize a piece of functionality (experimental -> stable in flowchart in li - **Whole feature flag, not part of a feature flag** It should be possible to enable just the experimental feature that is ready for stabilization *in isolation*, without also enabling other unstable functionality that is not ready for stabilization. - We are not allowed to propose to stabilize part of an experimenal feature and do so immediately. + We are not allowed to propose to stabilize part of an experimental feature and do so immediately. We have to first break out the candidate functionality to be stabilized so it is just guarded by one feature flag. - **Self-Containment** @@ -297,7 +297,7 @@ Ramifications to the user experience from layering being public: - Both perspectives are equally valid, and neither is prioritized over the other - - While not going so far as to *insist* users are aware of layering and care about it, the layered archicture of Nix should be exposed to anyone that cares, and it shouldn't suddenly dissapear (as a mere implementation detail might). + - While not going so far as to *insist* users are aware of layering and care about it, the layered architecture of Nix should be exposed to anyone that cares, and it shouldn't suddenly disappear (as a mere implementation detail might). Some examples of ways the principles are upheld: diff --git a/rfcs/0140-simple-package-paths.md b/rfcs/0140-simple-package-paths.md index 0926166a7..8e50f698b 100644 --- a/rfcs/0140-simple-package-paths.md +++ b/rfcs/0140-simple-package-paths.md @@ -76,7 +76,7 @@ Check the following using CI for each package directory: ## PR 2: Automated migration -Automatically migrate to new directory structure for all _satisfiying definitions_ `pkgs.${name}`, meaning derivations defined as above using `callPackage`. +Automatically migrate to new directory structure for all _satisfying definitions_ `pkgs.${name}`, meaning derivations defined as above using `callPackage`. However automatic migration is only possible if: - Files don't need to be changed, only moved, with the exception of `pkgs/top-level/all-packages.nix` @@ -337,7 +337,7 @@ Context: It's possible to override the default `{ }` argument to `callPackage` b The alternative is to not allow that, requiring that `pkgs.${name}` corresponds directly to `callPackage pkgs/by-name/${shard}/${name}/package.nix { }`. - (-) It's harder to explain to beginners whether their package can use the new directory structure or not -- (+) The direct correspondance ensures that the package directory contains all information about the package, which is very intuitive +- (+) The direct correspondence ensures that the package directory contains all information about the package, which is very intuitive - (-) We're not at the point where we can have that though, custom arguments don't have a good replacement yet - (-) If a package previously didn't need custom arguments, it would be moved to the new directory structure. But when the need for a custom argument arises, it then requires moving it out from new directory structure and into the freeform structure of `pkgs/` again. - (+) It's easier to relax restrictions than to impose new ones diff --git a/rfcs/0146-meta-categories.md b/rfcs/0146-meta-categories.md index 2ab31796d..dd6fc4564 100644 --- a/rfcs/0146-meta-categories.md +++ b/rfcs/0146-meta-categories.md @@ -49,7 +49,7 @@ However this system of categorization has serious problems: updated copy of the Nixpkgs tree. 3. The creation of a new category - and more generally the manipulation of - categories - requires an unpleaseant task of renaming and eventually patching + categories - requires an unpleasant task of renaming and eventually patching many seemingly unrelated files. - Moving files around Nixpkgs codebase requires updating their forward and @@ -318,7 +318,7 @@ There are remaining issues to be solved by the categorization team: - Documentation updates; - Category curation, integration and updates; - Continuous Integration updates and adaptations; - - Coordinaton of efforts to import, integrate and update categorization of + - Coordination of efforts to import, integrate and update categorization of packages; - Litigations and disputations: - Solve them, especially in corner cases;