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.
stdenvThese 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/46059 | |
| top level system | stdenv.hostPlatform.system | | |
| top level platform | stdenv.hostPlatform.platform | | https://github.com/NixOS/nixpkgs/pull/45403 |
stdenv but bad for being unclear which platformWe may wish to keep some of these to "steer" people towards the host platform, however.
| Attribute | Use instead | Deprecated in | 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.
stdenv and fully explicit, so goodJust putting here for reference
stdenv.{build,host,target}Platform.systemstdenv.{build,host,target}Platform.platformstdenv.{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;
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.mkDerivation will get it's platforms from the stdenv fields to get the shifted directions.
[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.
stdenv.{build, host, target} (no Platform suffix) be more convenient or more 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
Dropping the Platform suffix would be confusing to me, fwiw. stdenv.build would leave a lingering "what?" in my mind.
@joachifm In the linked PR, I didn't shorten the names. Thanks for leading the vote.
馃憤 on stdenv having those attributes
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
https://github.com/NixOS/nixpkgs/pull/45403 did some work.
https://nest.pijul.com/pmeunier/carnix/discussions/12 autogenerated code blocks the removal of top-level {build,host,target}Platform.
https://github.com/NixOS/nixpkgs/pull/45717 deprecates things allowing for their later removal.
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.
Most helpful comment
Dropping the
Platformsuffix would be confusing to me, fwiw.stdenv.buildwould leave a lingering "what?" in my mind.