I feel having too many ways to do the same thing confuses new users, who assume the different ways do different things for reasons they don't know. I also don't like how the older ones are ambiguous given the "always cross" philosophy (native and identity cross should be same thing): it's not immediately clear which of the 3 platforms is being referred to. To that end, I propose deprecating, and maybe eventually removing, a bunch of interfaces.

Bad for being at the top level, rather in stdenv

These can all go.

In stdenv but bad for being unclear which platform

We may wish to keep some of these to "steer" people towards the host platform, however.

Note for stdenv.system: it appears Nix needs system on all derivations, including stdenv, to decide where to build them. But we can builtins.removeAttrs after creating the derivation.

In stdenv and fully explicit, so good

Just putting here for reference

• stdenv.{build,host,target}Platform.system
• stdenv.{build,host,target}Platform.platform
• stdenv.{build,host,target}Platform.is*

Original description

Would it be better if we did stdenv.{build, host, target}Platform instead of just {build, host, target}Platform with that being an additional argument? Should both be possible? @bjornfor at least mentioned this once.

Steps to change:

• pkgs/stdenv/generic/default.nix will take buildPlatform, hostPlatform, targetPlatform, and postTargetPlatform. This is because those are the platforms of the stdenv itself---not packages built with the stdenv. The parameters are not inherited, but rather bound one shifted over:

  let
    buildPlatform = hostPlatform;
    hostPlatform = targetPlatform;
    targetPlatform = postTargetPlatform;

  mkDerivation will get it's platforms from the stdenv fields to get the shifted directions. Nah, no stdenvs care about what platform they are built on. So, let's just skip this for now. It's more correct in a pedantic way, but it is also annoying. Edit: with Does stdenv need to be a derivation? #27178, the simple way is plenty correct as stdenv no longer has it's own build phase: it's just a nix expression.

• pkgs/top-level/stage.nix will loose its platform parameters; the stage's platforms will be defined by the stdenv. The documentation of those parameters I suppose can be moved to their new home in pkgs/stdenv/generic/default.nix?

• If we want to support what I have been doing so far, we will inherit the platforms in some extends function in the fixpoint in stage.nix, rather than the other way around. Conversely s/^(, (build|host|target)Platform)*// on every file is easy and will probably work. I learn towards having one way to do things.

• Would stdenv.{build, host, target} (no Platform suffix) be more convenient or more confusing? The crowd has spoken. That would be confusing.

Relatedly, here are some other attributes and the fate I want to destine them:
(see above)
I don't know if we need a deprecation cycle, or we can just remove right now.

I am coming around to this, because it makes removing old attributes easier. Comment and vote!

CC @Dridus @matthewbauer @vcunat @dezgeg @copumpkin @nbp