Nixpkgs: Never put `buildInputs` and `propagatedBuildInputs` on the PATH

Created on 17 Aug 2017  路  10Comments  路  Source: NixOS/nixpkgs

I'll soon fix https://github.com/NixOS/nixpkgs/issues/21191: ensuring they aren't are on the PATH when cross compiling. But it would be more consistent do do that regardless of whether we're cross compiling, so that cross builds are less likely to fail assuming the native ones get more testing.

enhancement stale cross-compilation

Most helpful comment

I run into this a surprising amount, especially when building LLVM-based tools (things that look for LLVM and Clang headers). I can imagine it's even more painful for cross-compilation. Because it's amusing terrible-- my solution usually is to add 'stdenv.cc' as an input, being careful to order it so that the right CC appears in PATH first... :sob:

All 10 comments

This sort of fundamental change to mkDerivation belongs to https://github.com/NixOS/rfcs, I think.

I consider it more a bug with the status quo than a design deviation, but sure it is certainly very breaking so I can write one.

I run into this a surprising amount, especially when building LLVM-based tools (things that look for LLVM and Clang headers). I can imagine it's even more painful for cross-compilation. Because it's amusing terrible-- my solution usually is to add 'stdenv.cc' as an input, being careful to order it so that the right CC appears in PATH first... :sob:

This goal is definitely desirable. But how do we express a dependency of PackageA on PackageB where PackageA calls PackageB from the command line? For example, @svanderburg's composer2nix depends on nix-prefetch-scripts, because it calls nix-prefetch-url via shell_exec.

Can we always patch PackageA so it calls PackageB using the full path to the PackageB executable?

Do we need the concept of "peer dependencies"? (I hope not!)

I ran into this in issue https://github.com/NixOS/nixpkgs/issues/41613, but I was able to work around it by modifying the "internal" PATH used by Vim.

If you wan't cyclic dependencies, you're out of luck (simple answer). But if you just want build-time acyclic PATH, use nativeBuildInputs.

@Ericson2314, not sure if that response was for me, but for my use case, I don't want cyclic dependencies. I need a run-time environment that matches the build-time environment of buildInputs. Right now, I get around that by using buildInputs and then calling the full path to the binary of the dependency I need at run-time, e.g., if I need date at run time, I call ${coreutils}/bin/date.

@ariutta Yes; sorry for no ping.

Ah! that makes more sense. What you want is @matthewbauer's improved patchShebangs (https://github.com/NixOS/nixpkgs/pull/43833), which is do exactly that: patch the shebangs of installed things based on buildInputs and other run-time deps.

@Ericson2314, thanks, that sounds great.

Was this already done to buildPythonPackage and buildPythonApplication in 19.03? See #60243. What a breaking change!

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

  1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
  2. Ask on the NixOS Discourse.
  3. Ask on the #nixos channel on irc.freenode.net.
Was this page helpful?
0 / 5 - 0 ratings

Related issues

copumpkin picture copumpkin  路  3Comments

ghost picture ghost  路  3Comments

yawnt picture yawnt  路  3Comments

grahamc picture grahamc  路  3Comments

rzetterberg picture rzetterberg  路  3Comments