Reduce redundant ways to inspect the platforms

Ericson2314 commented 7 years ago

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.

Attribute	Use instead	Deprecated in	Removed in
top level `{build,host,target}Platform`	`stdenv.{build,host,target}Platform`	https://github.com/NixOS/nixpkgs/pull/209816
top level `system`	`stdenv.hostPlatform.system`
top level `platform`	`stdenv.hostPlatform.platform`		https://github.com/NixOS/nixpkgs/pull/45403

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.

Attribute	Use instead	Removed in
`stdenv.system`	`stdenv.hostPlatform.system`
`stdenv.platform`	`stdenv.hostPlatform.platform`	https://github.com/NixOS/nixpkgs/pull/45403
`stdenv.is*`	`stdenv.hostPlatform.is*`

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:

[x] 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 https://github.com/NixOS/nixpkgs/issues/27178, the simple way is plenty correct as stdenv no longer has it's own build phase: it's just a nix expression.
[x] 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?
[x] 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

joachifm commented 7 years ago

Dropping the Platform suffix would be confusing to me, fwiw. stdenv.build would leave a lingering "what?" in my mind.

Ericson2314 commented 7 years ago

@joachifm In the linked PR, I didn't shorten the names. Thanks for leading the vote.

copumpkin commented 7 years ago

👍 on stdenv having those attributes

Ericson2314 commented 5 years ago

Let's also remove top-level {build,host,target}Platform as @dezgeg requests.

I should make a final push on the less visible parts of of this before 18.09

Ericson2314 commented 5 years ago

https://github.com/NixOS/nixpkgs/pull/45403 did some work.

Ericson2314 commented 5 years ago

https://nest.pijul.com/pmeunier/carnix/discussions/12 autogenerated code blocks the removal of top-level {build,host,target}Platform.

Ericson2314 commented 5 years ago

https://github.com/NixOS/nixpkgs/pull/45717 deprecates things allowing for their later removal.

stale[bot] commented 3 years ago

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.

stale[bot] commented 3 years ago

I marked this as stale due to inactivity. → More info

Artturin commented 1 year ago

moving {build,host,target}Platform to aliases https://github.com/NixOS/nixpkgs/pull/209816

nixos-discourse commented 6 months ago

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/stdenv-isdarwin-stdenv-isaarch64-vs-aarch64-darwin/37922/1

NixOS / nixpkgs