Nah, I don't think there's a need to deprecate anything.

I'm probably getting confused by build/host/target again, but shouldn't the source tarball conditions use targetPlatform?

Current state of this PR's changes is confusing:

"... Please use stdenv.system or stdenv.hostPlatform.system."
"stdenv.system is deprecated since 18.09. Please use stdenv.hostPlatform.system."

Hehe that's me hoping the first PR is more palatable than the second. It would be nice to at least get the whole suite of "top-level depreciations" if they both really would like stdenv.system to stay in place.
.system`.

Is this a real use-case?

Yes, this is a real use-case: NixOps has to support multiple NixOS versions. So deprecation warnings are annoying because either we get warnings on newer NixOS versions, or we fix the warnings and break support for the older versions.

What versions of NixOS does NixOPS currently attempt to support? Is this documented anywhere?

Also, I offer to personally backport stdenv.*Platform.system to prior NixOS versions. It would be wrong for the limited version of cross compilation those offer, but that's fine.

But you do need to check for the specific architecture from time to time.

That is not OS-specific, so it should be done not with system but with:
stdenv.hostPlatform.isArm && stdenv.hostPlatform.parsed.cpu.version <= 6
That's a totally legit use-case, but not one which I think is common enough to deserve a shorthand.

These system strings are what I and other people know, this other stuff I have no idea even existed. (And given these sort of checks are needed only in ultra rare situations, probably shouldn't since to me they seem to raise more questions than they answer, e.g what's this stdenv.hostPlatform.parsed.cpu.version even gonna return on an x86_64? Will it return "5tel" or 5 on armv5tel-linux?). Now yes that will assume Linux, but that's the only OS supported on ARMv6 anyway and the chances of that changing are literally so low I won't be thinking about that. In fact I don't even know if -latomic is needed on non-GCC-using platforms or is it actually going to break things there.

(Even then, it is bad for platforms with more than one ABI and hostPlatform.config is a better choice).

Same thing, if there is no real practical difference, the interface that people know is better.

I think the main reason to deprecate stdenv.system is the confusion as to what system it is applying to. Is it the system building the software or the system that will run the software. This applies to stdenv.is* as well, though.

Both Buildroot and OpenWRT seem to have e.g. BR2_x86_64 and CONFIG_x86_64 which are exactly equivalent to our stdenv.isx86_64 and there seems to be no confusion.

These system strings are what I and other people know, this other stuff I have no idea even existed.

So what? The deprecation warning brings awareness to the new interface. It's absurd to argue against advertising the new interface and then complain it's not well known.

Will it return "5tel" or 5 on armv5tel-linux?

5

e.g what's this stdenv.hostPlatform.parsed.cpu.version even gonna return on an x86_64?

The field is only present for ARM, as it's not clear what it should be elsewhere when we don't have multiple versions anyways.

Now yes that will assume Linux, but that's the only OS supported on ARMv6 anyway

iOS. I do use Nix and nixpkgs to build iOS apps for work, so this is not at all hypothetical.

But that to me is besides the point. Except for things like prebuilt binaries, it's usually clear when some change is because of the OS or because of the CPU. If say, we're supporting aarch64-linux, some arm-linux, and x86_64-linux, two orthogonal conditions is much better style than one fat condition on the system. It's crucial to push the interfaces coax developers in the direction of better code.

In fact I don't even know if -latomic is needed on non-GCC-using platforms or is it actually going to break things there.

It is not unlikely one would want to use Clang for these things. compiler-rt provides atomics too, but either library can be used.

Same thing, if there is no real practical difference, the interface that people know is better.

As an aside, I'm not even sure it is a better known interface. Outside of Nix I probably see x86_64-unknown-linux-gnu more than x86_64-linux.

But yes, I do concede that at the moment prebuilt binaries tend do only bother with one ABI per CPU+OS.

IMHO, we should really reconsider whether these gratuitous deprecations/removals/renames are a good idea. They all add a little bit of friction to each NixOS upgrade, which, given enough of them, adds up to a lot of friction. Ideally you should be able to try out a newer NixOS version without having to make lots of little changes to your configuration modules / Nix packages, and to use those in multiple NixOS versions without having to put in lots of version conditionals.

I guess this won't make it into 18.09 or 19.03 ;-)

I updated the PR title. I think we should come to a consensus about deprecations. Could somebody revive RFC 0033?

Yes this is blocked on that RFC, which I do mean to get back to. (I am technically coauthor but haven't done anything yet!! 😲).

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.

rfc33 was closed. Should we keep this one open?

As stated by @Ericson2314 in #45717 (comment), this is blocked on an RFC, which is yet to be revived.

I propose closing it for now - as the PR doesn't apply cleanly either and is not actionable atm.

Find with me