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