https://github.com/jonringer/rename-cross-deps-proposal
Proposal to rename stdenv.mkDerivation inputs to something more ergonomic
https://github.com/jonringer/rename-cross-deps-proposal
Last synced: 4 months ago
JSON representation
Proposal to rename stdenv.mkDerivation inputs to something more ergonomic
- Host: GitHub
- URL: https://github.com/jonringer/rename-cross-deps-proposal
- Owner: jonringer
- License: cc-by-sa-4.0
- Created: 2024-09-15T20:03:42.000Z (almost 2 years ago)
- Default Branch: master
- Last Pushed: 2025-01-08T22:34:38.000Z (over 1 year ago)
- Last Synced: 2025-05-18T15:44:29.017Z (about 1 year ago)
- Size: 11.7 KB
- Stars: 3
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE.txt
Awesome Lists containing this project
README
---
Title: Rename dependency inputs to be more intuitive
Author: jonringer
Discussions-To: https://github.com/NixOS/nixpkgs/issues/28327
Status: Draft
Type: Standards Track
Topic: Packaging
Created: 2024-9-15
---
# Summary
The names `nativeBuildInputs` and `buildInputs` are often unintuitive to newcomers
and don't fit into the more normalized naming of `deps` established
in [nixpkgs#26805](https://github.com/NixOS/nixpkgs/pull/26805). This proposal
tries to adopt more ergonomic naming of derivation dependencies based on learnings
from when nixpkgs#26805 was implemented in 2017. This is to lower the "oddity budget"
of using nixpkgs.
## Detailed Implementation
| Current Names | Legacy Names | Proposed Names | Simple Description | Example |
| -------- | ------- | ---------- | -------------- | --------- |
| depsBuildBuild | | bootstrapDeps | Dependency is a compiler, which produces things for buildPlatform. | `autotools` checking compiler compatibility may build and run built programs, these cannot target Host or Target platforms |
| depsBuildHost | nativeBuildInputs | buildtimeDeps | Dependency is a tool which runs on the build platform, but produces code which runs on host | `cmake`, `meson`, `ninja` |
| depsBuildTarget | | **removed** | Dependency is a compiler, but produces code not for host, but for target platform. This is bad. | **none** |
| depsHostHost | | **removed** | Dependency runs on host platform, and can be used only during build. Currently depsBuildBuild is used instead. | **none** |
| depsHostTarget | buildInputs | runtimeDeps | Dependency is the same as this derivation. Runs on host, produces code for target platform | C/C++ libraries |
| depsTargetTarget | | targetDeps | Dependency needs to be used/injected unaltered at runtime by package we're building | gobject-inspection |
Currently these are implemented as a "doubly linked list" where you can go forward and backward
between `stdenv`s which target different build/host/target triplets. Also, a spliced package
set is needed to pass a spliced drv which can provide the correct variant. E.g. `drv.__spliced.deps`
```
# pkgs/stdenv/booter.nix
# depsHostTarget is assumed to be `thisStage` in this context, thus omitted from adjacentPackages
adjacentPackages = if args.selfBuild or true then null else rec {
pkgsBuildBuild = prevStage.buildPackages;
pkgsBuildHost = prevStage;
pkgsBuildTarget =
if args.stdenv.targetPlatform == args.stdenv.hostPlatform
then pkgsBuildHost
else assert args.stdenv.hostPlatform == args.stdenv.buildPlatform; thisStage;
pkgsHostHost =
if args.stdenv.hostPlatform == args.stdenv.targetPlatform
then thisStage
else assert args.stdenv.buildPlatform == args.stdenv.hostPlatform; pkgsBuildHost;
pkgsTargetTarget = nextStage;
};
```
`depsBuiltTarget` and `depsHostHost` were previously aliased to "whatever made the most
sense", however, have not come to be used in practice in nixpkgs. The only mentions
are of stdenv mkDerivation helper's which attempt to support spliced package sets
out of completeness.
## Example cross-compilation use case
The most common use case for this would be `pkgsCross.aarch64-multiplatform` in which case the build, host, target platforms from an x86_64 machine would be:
| Platform | System |
| -------- | ------ |
| Build | "x86_64-linux" |
| Host | "aarch64-linux" |
| Target | "aarch64-linux" |
In the vast majority of cases, just buildtimeDeps and runtimeDeps need to be specified:
```nix
{ stdenv, cmake, openssl }:
stdenv.mkDerivation {
...
# CMake is used at buildtime, to produce code for the host platform
buildtimeDeps = [ cmake ];
# openssl is used during the build for the host platform, producing code for the target platform
runtimeDeps = [ openssl ];
...
}
```
## Migration plan
Migration plan consists of supporting "both" paradigms while the poly-repo fork
is still translating work from upstream nixpkgs. Eventually, existing dependency
names should be formally deprecated with a warning. It is currently unknown if
the existing input labels will be unsupported in the future.
## Future work
- Determine appropriate date for formally deprecating existing input names
- Determine if existing names should be supported for backwards compatibility with existing nix expressions
## Relevant topics
- https://github.com/NixOS/nixpkgs/issues/28327#issuecomment-879815573
## Adjacent issues
- Package splicing pain in general, how to improve the implementation:
- https://discourse.nixos.org/t/frustrations-about-splicing/49607
- https://github.com/NixOS/nixpkgs/issues/204303
- Propagated vs not propagated inputs:
- https://discourse.nixos.org/t/the-papercut-thread-post-your-small-annoyances-confusions-here/3100/24