I should have checked more carefully.

There's a function called makeOverride that deprives the input builder of their recursive attributes support, and buildPythonPackage and buildPackageApplication happens to be makeOverrided. While the change keeps the current python packages unchanged, it still doesn't bring the recursive attributes support to buildPythonModule and buildPythonApplication unless we fix makeOverridable.

Updat: fixed, see below.

Fix lib.makeOverridable and makeOverridablePythonPackage. Now buildPython* accepts recursive attributes.
Turn a Python application pyspread into the recursive attributes style.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/proposal-move-values-from-derivation-attributes-to-function-arguments/20697/21

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/avoid-rec-expresions-in-nixpkgs/8293/18

Recently the Packages Modules Working Group started investigating whether something like the module system could be used to evaluate packages. We're tracking all work in this repository, meeting weekly, but working mostly asynchronously. It would be great if you could join the Matrix room of the WG and chat with us, or even join the team yourself to work on such issues!

Thank you for taking time reviewing this!

I'm concerned about the increasing complexity, while the goal can be achieved through simplification instead: removing the python-specific level of overriding and turning it into an "overlay" on the mkDerivation arguments instead.

The idea to shift workflow-specific overlays sounds neat, and that could also be friendlier when packaging multi-language projects. Nevertheless, there are some issue on the way to the switch:

1. Current builders rely more or less on arguments they won't pass into mkDerivation attribute set.
   Developers would need to change the way they handle the arguments / attributes, either by passing them directly or through passthru. The impl input argument of the proposed function is essentially an overlay that allows passing not-to-pass-to-mkDerivation arguments through the previous set.

2. Current attempt to try to implement a builder that supports the (finalAttrs: { }) through an overlay passing to .overrideAttrs, such as rustPlatform.buildRustPackage: support finalAttrs style #194475, discards the set pattern of input arguments ({ a, b ? "some default", ... }@args) completely and degenerate it into previousAttrs.
   It is a pity, since the set patterns itself serves as an interface of the builder, providing information about the expected input arguments to both and the Nix interpreter and people reading the Nix expression.
   The solution would be rather simple -- replace the previousAttrs with the set pattern, and then the remaining issue will be point 1.

Overall, the goal of the proposed function is to add (finalAttrs: { }) input support with minimum changes to the existing expressions, and raise the discussion about general approaches to bring such supports to builders.

Just reviewing your change to input-remapper, I like how much this cleaned up its definition. :)

Backport failed for release-24.11, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin release-24.11
git worktree add -d .worktree/backport-234651-to-release-24.11 origin/release-24.11
cd .worktree/backport-234651-to-release-24.11
git switch --create backport-234651-to-release-24.11
git cherry-pick -x 2439ead79150130e48f6c45409337125f4250685 bbdf8601bcf2a7e733d5ef2552109a5d8d5a44ce

We should manually backport all of these PRs. Without these, new package PRs changing to finalAttrs will break eval.

• What's the risk of backporting this PR?
• Will anyone want to backport packages that need this PR?

We should manually backport all of these PRs. Without these, new package PRs changing to finalAttrs will break eval.

After a night to sleep on it, I agree. I've done so in #390950. Please take a look. It was not so difficult.

@philiptaron Based on our previous discussion about the name "derivation constructor" instead of "build helper", would you like to persue a tree-wide (wlole-Nixpkgs-Manual) renaming?

I wouldn't be in favor of a more cumbersome word for something which I think is already described precisely enough by "build helper" (since it's a convenience wrapper for building software, a special case of constructing derivations).

I'll defer to Valentin (@fricklerhandwerk) as a representative of @NixOS/documentation-team though I do not share his perspective. I wouldn't merge that update without some rough consensus on it.

Thank you both for the input.

I'm drafting a Nix RFC which heavily uses the phrase "build helper," and I'm just trying to make sure that the wording wouldn't get obsolete in the near future.

My critique of "build helper" is sort of pedantic, but here it is. This is likely the wrong place to have the discussion, too, so I'd appreciate a redirect to a better place.

As a word, "helper" doesn't mean anything specific. It could be a binary, it could be a hook, it could be // adding more attributes into an attrset... anything that in any sense "helps" can be described as a "helper". So I'd prefer not to call something a helper if there is at all a more specific word.

As a word, "building" is what happens when a derivation is actually realized and instantiated. That's what section 4.5 of the Nix manual, titled "Building", uses to describe the process.

Therefore, the derivation isn't in any sense a "build". It's a derivation, which when "built" will produce some set of outputs.

The word that the Nix manual uses for what stdenv.mkDerivation returns, as I read it, is "derivation expression". It's an expression in the Nix language that yields a derivation. Simple enough.

As I read it, though, that's the combination of the Nix function with its arguments. That's the "derivation expression". So we need a word for the function that, when called with suitable arguments, is a "derivation expression". We could call these "derivation-returning functions", but that's quite general and a bit wordy. So, the best I can come up with is a "derivation constructor" -- some Nix function that, when called, "constructs" a derivation. The most simple "derivation constructor" would be derivationStrict. A mid-level one would be stdenv.mkDerivation. Something like rustPlatform.buildRustApplication would be at the high end of complexity. But they'd all be caught under this term.

So that's the argument, @fricklerhandwerk, both against using "build helper" as a name for these things and in favor of using "derivation constructor" for it.

Thanks @philiptaron, greatly appreciate the elaboration! I see your points and fully agree on the grounds of being precise. My point is that it's sometimes meaningful to trade ease of use (which also relates to existing habits) against precision, at least to some degree, and that's one thing that makes naming hard.

That said, while I wouldn't be in favor of a change, I wouldn't be against a more precise term either that ideally would be easy to adopt for both new and habitual users. And in any case, I'm not the boss of Nixpkgs terminology! A good place to discuss this would be a PR proposing the change, and giving it a bit more exposure by posting it on Discourse.