pkgsStatic: do not propagate builds with nix-support/propagated-build-inputs

[FRidh]

Describe the bug
For static builds recursively all dependencies are needed. An adapter is now used that converts all buildInputs to propagatedBuildInputs. Using propagatedBuildInputs results in the file $out/nix-support/propagated-build-inputs causing a run-time dependency on all build-time dependencies.

With Python there is a similar kind of issue which is why there I am investigating a way that does not involve writing out that file.

[tobim]

Here is an Idea:

Instead of modifying nix-support, pkgsStatic can clone the same mechanism into a separate store path. I.e., the adapter adds an implicit output "nix-static-inputs" that contains the paths that are currently added into propagated-build-inputs. The adapter can then make use of that file to insert those dependencies back into the build environment.

I don't know if that would be viable for Python too.

What do you think?

[FRidh]

Maybe. Imagine we go create Python packages with pkgsStatic. Both use propagatedBuildInputs, but for different purposes. How do you distinguish?

The whole file is not needed here in case of pkgsStatic, the stdenv recurses without it if I am correct. The file is used in case of e.g. interpreted languages but even there its a simplified solution.

Possible solutions

1. keep using propagation but put it in a separate output, dev
2. remove the file with a hook
3. new attribute that propagateBuildInputs sets, that we recurse in, as is partially done for Python with requiredPythonModules.

1 and 2 will break other use case of propagatedBuildInputs, though likely they also shouldn't be using it.

[FRidh]

cc @Ericson2314 @matthewbauer for input. Generally speaking, propagating inputs does not mean we want to have them typically written out in nix-support/propagated-build-inputs.

[FRidh]

Ah, nix-support already ends up in dev. So it's just a matter of adding dev outputs everywhere.

[Ericson2314]

Ah yes @FRidh beat me to it. The intension I always assumed was to have dev outputs everywhere, though I am not sure how well that works with all languages.

[bhipple]

Yes that's my understanding as well, the dev outputs are always transitively propagated. One thing I'm not entirely sure of though is whether a multiple-output package that has a setupHook still has all of its transitive setupHooks executed for a dev dependency, like it will for propagatedBuildInputs or direct buildInputs.

[FRidh]

The intension I always assumed was to have dev outputs everywhere, though I am not sure how well that works with all languages.

Python libraries that don't have any executables will loose their store references until the library is used in an environment. Not a big issue but it can cause unnecessary GC and fetching. Note we're not using dev yet for Python packages.

[FRidh]

Example of a change forcing a "dev" output for static builds #83793

[stale]

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.