Nixpkgs: Rename dependency attributes

[Ericson2314]

nativeBuildInputs, buildInputs, propagatedNativeBuildInputs, and propagatedBuildInputs are horrible names:

• Word order + capitalization impedes easy grepping
• native is vague wrt cross compilation
• build time vs run time usage is unclear
• both the host platform and target platform of dependencies can be varied, so in fact there is 2 axis of "native" vs "foreignness"

In https://github.com/NixOS/nixpkgs/pull/26805 I do add 4 more sorts of dependencies giving us:

| Current name | @Ericson2314's Ideal name | Host is | Target is |
|--------------------|----------------|----------|-------------|
| depsBuildBuild | depsBuildBuild | build platform | build platform |
| nativeBuildInputs | depsBuildHost | build platform | host platform |
| __depsBuildTarget | __depsBuildTarget | build platform | target platform
| __depsHostHost | __depsHostHost | host platform | host platform
| buildInputs | depsHostTarget | host platform | target platform
| __depsTargetTarget | __depsTargetTarget | target platform | target platform |

A disadvantages of these names, per the comments below, is for the vast majority of deps the target platform is irrelevant---my names are unintuitive and noisy in this case.

N.B. I'd love to structure things purely when the deps are needed---run time or build time---which is a pretty understandable concept even for those who have never heard of cross compiling. But this just isn't correct (yet). Firstly, it isn't enough granularity---see when dependent's host = depender's build, there's 3 possible target platforms. Worse, host=host dependencies may be used in all possible ways: only at build-time (static linking), only at run-time (dynamic loading of plugin library), or both (linking and headers).

---

A completely different approach would be rely more on language-specific builders: For C, let people think in terms of headers (and pkg-config files, etc) and libraries (dynamic or static), and then C-specific infrastructure would take care of everything behind the scenes regarding propagation and multiple outputs. I should probably elaborate this approach more fully in the another issue or RFC.

Split out from https://github.com/NixOS/nixpkgs/issues/4855

CC @dezgeg @edolstra

[matthewbauer]

Ok quick question: once you get an stdenv built, host will always equal build, right? The average package maintainer can assume they're the same, I think.

[ip1981]

Please don't use Target. It's confusing and irrelevant to the most software. Build inputs should be "host", native build inputs -"build".

[lprndn]

Passing by, I just wanted to give my humble point of view for the new names.
First of all, I'm not an expert user, more like intermediate, meaning that I don't really know what are the internals of nix* but I can build some packages on my own.
I do agree that current name should change and I don't doubt of the technical reasons behind the new ones. What worries me is that, if someone, like me, doesn't have the necessary knowledge (which I think is not basic and shouldn't be expected from an average user), it just doesn't make sense.
For example, buildInputs is not perfect but I can quickly get it. If I had stumbled upon depsHostTarget while reading my first nix expression, I might still be trying to wrap my mind aroud it, reading GNU docs...

I think that, at least for the most commonly used functions, it could be nice to use names that don't actually tell how that function works but what it is used for (aka what you need when you dont know internals). But it is a design choice.

It's not really mandatory and it's the kind of question that can stuck a PR for ages but I just wanted to remind we can choose to take that into account. (or not btw)

Have a nice day,

[Ericson2314]

See my edited OP----I originally wanted to just talk about build time vs run time, as that makes sense without thinking about cross compilation, but that breaks down pretty quick.

[ip1981]

In fact, using "build inputs" for "_host_ build inputs" (GNU style) and "native build inputs" for "_build_ build inputs" (tautology, yeah) is another commonly recognized scheme. Typical example are C/C++ libraries and code generators: libraries are almost always "build inputs" (or _host_ build inputs in GNU style) and code generators are native build inputs (_build_ build inputs).

So, to me, current state of buildInputs and nativeBuildInputs is _fine_ (as long as we talk about interface for package developers). If there is some internal inconsistency, it better be fixed, true.

[Ericson2314]

@ip1981 Well, take solace in the fact that I don't think I'll be renaming anything anytime soon. I might land the new deps with those names, but they are all rather obscure so will be easy to rename later----I could __-prefix them all to indicate instability too.

[vcunat]

@matthewbauer: no. It's quite common e.g. for embedded HW that you build everything on x86_64 even though your host will be different, because it would take much longer to build directly on the weak HW.

[grahamc]

Not doable for 18.09.

[Ekleog]

(triage) This will likely need an RFC, as it's a difficult balance to strike between simplicity and ease.

[stale[bot]]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.