This is a red-herring, and I suspect due to a unit test that's
too close to the underlying implementation. I've tested building
a couple of snaps with the new version of craft-parts (including)
ones which use the `python` plugin, and things seem to work
fine.
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
This focuses on Rust packages, since the most commonly used argument
parser library (clap/structopt) makes the following pattern natural and
thus common:
postInstall = ''
installShellCompletion --cmd foo \
--bash <($out/bin/foo completion bash) \
…
This commit just guards those with
lib.optionalString (stdenv.buildPlatform.canExecute stdenv.hostPlatform)
splitting the string where unrelated actions are performed.
Otherwise references to the Python interpreter inside the set are wrong, as demonstrated by:
``` nix
with import <nixpkgs> { };
let
python' = python3.override {
packageOverrides = final: prev: { requests = prev.requests.overridePythonAttrs(old: { version = "1337"; }); };
};
in python'.pkgs.python.pkgs.requests
```
which returns the _non_ overriden requests.
And the same with `self`:
```
with import <nixpkgs> { };
let
python' = python3.override {
self = python';
packageOverrides = final: prev: { requests = prev.requests.overridePythonAttrs(old: { version = "1337"; }); };
};
in python'.pkgs.python.pkgs.requests
```
which returns the overriden requests.
This can manifest itself as file collisions when constructing environments or as subtly incorrect dependency graphs.
