I have a question regarding the Python build infrastructure and runtime dependencies.
To denote a run-time dependency for a python package, what one does is to put it in
propagatedBuildInputs. This has always struck me as somewhat odd in terms of how things are named. That is: if it’s really just a run-time dependency, why put it in the build inputs? However, I do somewhat understand that this works in practice: the inputs are propagated to the closure of the python-with-pacakges that includes the python module, and in that way all packages have each other available at run-time.
However, I wonder whether this approach is not unnecessarily wasteful / overly conservative when actually building the packages: if a package is expensive to build (e.g. pandas) it will still be fully rebuilt whenever one of its dependencies is updated: even if those dependencies don’t actually come into play until runtime. I.e. even if those dependencies do not actually affect the build.
(I realize that one could argue that, when the process of building the package includes running the tests, the runtime dependencies actually become build-time dependencies… let’s ignore that for the moment, or imagine that we might change our infrastructure such that building (i.e. compiling) the package is separated out from the testing phase).
Is my thinking correct here? And is there such a thing in Nix as a runtime-only dependency, which could be used to mitigated the abovementioned wastefulness?