It is an anti-pattern to use pkgsCross because it make eval times worse, as each new stdenv named must eval a new Nixpkgs set. It is also fragile as one is focing the native stdenv to use build for another platform often, or just duplicated work. It has been thrown around to remove pkgsCross from callPackage at some point.
The solution is to make the derivation cross-happy, then to write something like pkgsCross.aarch64-multiplatform.myPackage or whatever is being done. And if caching is desired, add it to releases-cross.nix.
You can see an example of how this was solved here:
NixOS/nixpkgs#534687
Went from NixOS/nixpkgs@03276ae#diff-cfbc5f8218e332474b1f9827496f35b84267fb0fddc11910b8bdfc9505c61b72
Where pkgsCross is used explicitly, to https://github.com/NixOS/nixpkgs/pull/534687/changes/d2ff8a9dbcfa221dda5c525508133b32e305dc86..4d894682215ca90d3f076779bfaa268b2e7a4c91
Where meta.platforms is set, and the packages are added to release-cross so they are cached.
Exactly how to reliably detect this is a good question. Most reliable would be reading the build closure to see if something pkgsCross-shaped is pulled in. But I don't think there is code for that in vet right now.
Not all naming is bad though. For example naming in passthru is generally fine (unless another package downstream uses it for building), so as shown in the above PR, using it for a withPackages helper is fine, or in passthru tests. It's just the Hydra eval'd attributes that should be avoided.
It is an anti-pattern to use
pkgsCrossbecause it make eval times worse, as each new stdenv named must eval a new Nixpkgs set. It is also fragile as one is focing the native stdenv to use build for another platform often, or just duplicated work. It has been thrown around to removepkgsCrossfromcallPackageat some point.The solution is to make the derivation cross-happy, then to write something like
pkgsCross.aarch64-multiplatform.myPackageor whatever is being done. And if caching is desired, add it toreleases-cross.nix.You can see an example of how this was solved here:
NixOS/nixpkgs#534687
Went from NixOS/nixpkgs@03276ae#diff-cfbc5f8218e332474b1f9827496f35b84267fb0fddc11910b8bdfc9505c61b72
Where
pkgsCrossis used explicitly, to https://github.com/NixOS/nixpkgs/pull/534687/changes/d2ff8a9dbcfa221dda5c525508133b32e305dc86..4d894682215ca90d3f076779bfaa268b2e7a4c91Where
meta.platformsis set, and the packages are added torelease-crossso they are cached.Exactly how to reliably detect this is a good question. Most reliable would be reading the build closure to see if something
pkgsCross-shaped is pulled in. But I don't think there is code for that in vet right now.Not all naming is bad though. For example naming in
passthruis generally fine (unless another package downstream uses it for building), so as shown in the above PR, using it for awithPackageshelper is fine, or in passthru tests. It's just the Hydra eval'd attributes that should be avoided.