└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # MOVED TO https://github.com/ekala-project/ekapkgs-roadmap 2 | 3 | # Poly-repo Nixpkgs Fork 4 | 5 | Why? Although a single mono-repo makes it easy for dealing with issues which 6 | span many language ecosystems or subtle software interactions, it also causes 7 | many maintenance issues. Issues like commit access giving "too much power", high 8 | noise to signal ration in issues and PRs for contributors, and other issues makes 9 | it difficult to maintain nixpkgs from a human perspective. 10 | 11 | ## Basic repository overview 12 | 13 | Repositories will be structured in a way where the most impactful packages 14 | can reside in the "stdenv" and "core" repositories. From this core, language 15 | ecosystem packages and other package ecosystems can branch off of core and these 16 | "vertical slices" can be curated independently from the others. The `pkgs` repository 17 | allows for all of these packages to be recombined through overlays into a single package set similar 18 | to nixpkgs. The `user-pkgs` overlay will allow for semi-official user packages to 19 | be added, and greater freedom for individuals to contribute their additions with 20 | less emphasis on dogmatic best practices. 21 | 22 | ```mermaid 23 | flowchart RL 24 | pkgs["Pkgs + PkgsModules"] 25 | Core["Core + CoreModules"] 26 | Stdenv --> Lib 27 | Core --> Stdenv 28 | Python --> Core 29 | Haskell --> Core 30 | Node --> Core 31 | etc... --> Core 32 | pkgs --> Core 33 | pkgs --> Python 34 | pkgs --> Haskell 35 | pkgs --> Node 36 | pkgs --> etc... 37 | UserPkgs --> pkgs 38 | ``` 39 | 40 | ## Repository descriptions 41 | 42 | All repositories will be Nix 2.3 compatible, with optional flake.nix entry points. 43 | 44 | - [x] [Standalone Lib](https://github.com/jonringer/nix-lib) 45 | - nixpkgs/lib but reduced to just nix utilities 46 | - lib.systems is moved to stdenv repo 47 | - lib.maintainers and lib.teams moved to core 48 | - [x] [Stdenv Repo](https://github.com/jonringer/stdenv): 49 | - Encapsulates bootstraping the `stdenv` package for platforms. 50 | - Handles package splicing and cross compilation concerns 51 | - Contains the logic for `pkgs.config` and overlay application 52 | - Maintained by a dedicated team of individuals 53 | - [x] [Core Repo](https://github.com/jonringer/core-pkgs): 54 | - Targeting "development and deployment" scenarios 55 | - Provides the stdenv.mkDerivations (e.g. buildPythonPackage) helpers 56 | - Provides a few thousand of the most common development dependencies 57 | - Desire here is to provide the 20% of packages which are used 80% of the time. 58 | - Bootstrap language ecosystem package sets. 59 | - Contains maintainer information 60 | - [ ] Language package sets: 61 | - Contain a top-level overlay and `overrideScope` of the package set with richer set of packages 62 | - [X] [Python Prototype](https://github.com/jonringer/python-pkgs) 63 | - [ ] Pkgs: 64 | - Targeting "User desktop" scenarios, most software will be available here 65 | - Combines all of the langauge package set overlays 66 | - Acts as the "backstop" for all packages which have "trickier" dependency requirements 67 | - [ ] User-pkgs: 68 | - The NUR/"AUR" equivalent. 69 | - Allows for people getting started with Nix to share expressions in a semi-centralized manner 70 | - Linting and basic concerns for code quality still upheld, but less of an emphasis from "official" overlays 71 | 72 | ## NixOS Modules 73 | 74 | - [ ] Core Modules 75 | - "Minimal" set of modules to create a usable NixOS system 76 | - Targeting mostly enterprise, edge compute, and single purpose systems 77 | - [ ] Pkgs Modules 78 | - "Complete" set of modules, appropriate for most end-users 79 | - Analogous to the current nixpkgs/nixos module collection 80 | 81 | ## Additional Proposals 82 | 83 | - [Ergonomic cross-compilation dependency terms](https://github.com/jonringer/rename-cross-deps-proposal) 84 | - [Language-ecosystem overlays as pkgs.config options](https://github.com/jonringer/language-specific-config-overlays-proposal) 85 | - [Standardize how packages expose versions/variants](https://github.com/jonringer/multiple-package-versions-proposal) 86 | - [Auto call polyPkgs to avoid awkward argument passing](https://github.com/jonringer/autocall-poly-pkgs-proposal) 87 | - [toDevShell function to provide easy dev shell creation for any mkDerivation drv](https://github.com/jonringer/to-dev-shell-proposal) 88 | - [Align nix expression file paths to attr path](https://github.com/jonringer/normalize-attr-to-path-proposal) 89 | - [Alternative to callPackage for non-derivations](https://github.com/jonringer/scope-import-proposal) 90 | - [Extend pkgs.config to allow for modules to be passed](https://github.com/jonringer/pkgs-modules-proposal) 91 | 92 | ## Addtional tooling 93 | 94 | - [ ] PR review site: https://github.com/jonringer/basinix 95 | - Attempt to make PR reviews less risky 96 | - Build downstream packages (e.g. nixpkgs-review style) 97 | - New builds, removed builds, newly succeeding, newly failing, still succeeding, still failing 98 | - [ ] Auto-updater similar to https://github.com/nix-community/nixpkgs-update, but: 99 | - Creates issues when an automatic bump failed 100 | - Logs of failed build to be easily accessible 101 | - Replace re-write rules with just invocations of `nix-update`? 102 | 103 | ## Crazy ideas 104 | 105 | - [ ] "GC root indexed artifact store" 106 | - Allow for a retention date to be passed to the post-build-hook so that nix builds can communicate how long something should live 107 | - This would likely need to be passed to jobset evaluation 108 | - Most likely use another tool to handling the gc root metadata 109 | - Aims to solve the "ever growing cache" concerns 110 | - [ ] "Nix evaulator which can retain a live heap of evaluated objects to make eval diffs quick and cheap" 111 | --------------------------------------------------------------------------------