Open FRidh opened 4 years ago
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?
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
dev
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.
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
.
Ah, nix-support
already ends up in dev
. So it's just a matter of adding dev
outputs everywhere.
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.
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
.
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.
Example of a change forcing a "dev" output for static builds https://github.com/NixOS/nixpkgs/pull/83793
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.
Describe the bug For static builds recursively all dependencies are needed. An adapter is now used that converts all
buildInputs
topropagatedBuildInputs
. UsingpropagatedBuildInputs
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.