Nixpkgs: Reduce redundant ways to inspect the platforms

Created on 3 Jul 2017  路  8Comments  路  Source: NixOS/nixpkgs

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/46059 | |
| 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 | 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.

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

enhancement question stale cross-compilation community feedback

Most helpful comment

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

All 8 comments

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://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.

Was this page helpful?
0 / 5 - 0 ratings