From 14b52848f8a7dc30a2e13c4f16e4fb8d777365f1 Mon Sep 17 00:00:00 2001 From: Vincent Ambo Date: Mon, 25 May 2020 16:39:18 +0100 Subject: docs(3p/nix): Add a README explaining the goals of the fork --- README.md | 1 + third_party/nix/README.md | 159 ++++++++++++++++++++++++++++++++++++++++++---- 2 files changed, 148 insertions(+), 12 deletions(-) diff --git a/README.md b/README.md index 82daa7a746..c5987232d9 100644 --- a/README.md +++ b/README.md @@ -33,6 +33,7 @@ Twitter][]. the services in this repository are deployed!) * `ops/besadii` contains a tool that runs as the git `post-receive`-hook on my git server to trigger builds on sourcehut. +* `third_party/nix` contains my fork of the Nix package manager ## Packages / Libraries diff --git a/third_party/nix/README.md b/third_party/nix/README.md index 48cb1685c7..785de38d41 100644 --- a/third_party/nix/README.md +++ b/third_party/nix/README.md @@ -1,20 +1,146 @@ -[![Open Collective supporters](https://opencollective.com/nixos/tiers/supporter/badge.svg?label=Supporters&color=brightgreen)](https://opencollective.com/nixos) +Nix, or rather tazjin's fork thereof +------------------------------------ -Nix, the purely functional package manager ------------------------------------------- +Nix is a new take on package management that is fairly unique. Because +of its purity aspects, a lot of issues found in traditional package +managers don't appear with Nix. -Nix is a new take on package management that is fairly unique. Because of its -purity aspects, a lot of issues found in traditional package managers don't -appear with Nix. - -To find out more about the tool, usage and installation instructions, please -read the manual, which is available on the Nix website at +To find out more about the tool, usage and installation instructions, +please read the manual, which is available on the Nix website at . -## Contributing +This repository is [tazjin](https://tazj.in)'s fork of Nix. + +## Fork background + +Nix is a fantastic project with over a decade of demonstrated +real-world usage, but also with quite a few problems. + +First of all, the project consists of two main components: The Nix +package collection ("[nixpkgs][]") and the package manager itself. + +The package collection is an enormous effort with hundreds of +thousands of commits, encoding expert knowledge about lots of +different software and ways of building and managing it. It is a very +valuable piece of software. + +The package manager however is an old C++ project with severe code +quality issues, little to no documentation, no consistent style and no +unit test coverage. + +Its codebase is larger than it needs to be (often due to custom +reimplementations of basic functionality) and is mostly ad-hoc +structured, making it difficult to correctly implement large-scale +improvements. + +In addition, the upstream Nix project is diverging from the opinions +of some community members via the introduction of concepts such as Nix +flakes. + +To counteract these things I have decided to fork Nix. + +## Fork goals + +The things listed here are explicitly in-scope for work on the fork. +This list is not exhaustive, and it is very likely that many other +smaller things will be discovered along the way. + +### nixpkgs compatibility + +This fork will maintain compatibility with nixpkgs as much as +possible. If at any point we do need to diverge, we will do it in a +way that is backwards compatible. + +### Code quality improvements + +Code quality encompasses several different issues. + +One goal is to slowly bring the codebase in line with the [Google C++ +style guide][google-style]. Apart from the trivial reformatting (which +is already done), this means slowly chipping away at incorrectly +structured type hierarchies, usage of exceptions, usage of raw +pointers, global mutability and so on. + +Another goal is to reduce the amount of code in Nix by removing custom +reimplementations of basic functionality (such as string splitting or +reading files). + +For functionality that is not part of the C++17 standard library, +[Abseil][] will be the primary external library used. + +### Explicit RPC mechanisms + +Nix currently uses homegrown mechanisms of interacting with other Nix +binaries, for example for remote builds or interaction between the CLI +and the Nix daemon. + +This will be replaced with [gRPC][]. -Take a look at the [Hacking Section](http://nixos.org/nix/manual/#chap-hacking) -of the manual. It helps you to get started with building Nix from source. +### New sandboxing mechanism + +Nix implements its own sandboxing mechanism. This was probably the +correct decision at the time, but is not necessary anymore because +Linux containers have become massively popular and lots of new tooling +is now available. + +The goal is to replace the custom sandboxing implementation with +pluggable [OCI runtimes][oci], which will make it possible to use +arbitrary container runtimes such as [gVisor][] or [systemd-nspawn][] + +### Pluggable Nix store backends + +The current Nix store implementation will be removed from Nix' core +and instead be refactored into a gRPC API that can be implemented by +different backends. + +### Builds as graph reductions + +A Nix derivation that should be instantiated describes a build graph. +This graph will become a first-class citizen, making it possible to +distribute different parts of the computation to different nodes. + +Implementing this properly will also allow us to improve the +implementation of import-from-derivation by explicitly moving through +different graph reduction stages. + +## Fork non-goals + +To set expectations, there are some explicit non-goals, too. + +* Merging these changes back into upstream is not a goal, and maybe + not even feasible. The core work has not even started yet and just + basic cleanup has already created a diff of over 40 000 lines. + + This would likely also turn into a political effort, which I have no + interest in. + +* Improved performance is not an (initial) goal. Nix performance is + very unevenly distributed across the codebase (some things have seen + a lot of ad-hoc optimisation, others are written like inefficient + toy implementations) and we simply don't know what effect the + cleanup will have. + + Once the codebase is in a better state we will be able to start + optimising it again while retaining readability, but this is not a + goal until a later point in time. + +* Compatibility with new upstream features is not a goal. Specifically + we do not want Nix flakes, but other changes upstream makes will be + considered for inclusion. + +* Support for non-Linux systems. Currently Nix support Mac OS and + potentially other systems, but this support will be dropped. + + Once we have OCI-compatible sandboxes and a store protocol it will + be possible to reintroduce these with less friction. + +## Contributing to the fork + +My repository's default [contribution guidelines][contributing] apply. + +In addition, please make sure that submitted code builds and is +formatted with `clang-format`, using the configuration found in this +folder. ## License @@ -22,3 +148,12 @@ Nix is released under the LGPL v2.1 This product includes software developed by the OpenSSL Project for use in the [OpenSSL Toolkit](http://www.OpenSSL.org/). + +[nixpkgs]: https://github.com/NixOS/nixpkgs +[google-style]: https://google.github.io/styleguide/cppguide.html +[Abseil]: https://abseil.io/ +[gRPC]: https://grpc.io/ +[oci]: https://www.opencontainers.org/ +[gVisor]: https://gvisor.dev/ +[systemd-nspawn]: https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html +[contributing]: https://git.tazj.in/about/docs/CONTRIBUTING.md -- cgit 1.4.1