Skip to content

Use lazy evaluation for dependencies of the zipDistributable task#1474

Open
neobrain wants to merge 1 commit intoprocessing:mainfrom
neobrain:nix-fix2
Open

Use lazy evaluation for dependencies of the zipDistributable task#1474
neobrain wants to merge 1 commit intoprocessing:mainfrom
neobrain:nix-fix2

Conversation

@neobrain
Copy link

@neobrain neobrain commented Mar 5, 2026

The createDistributable task is generated by the Compose plugin, so it's not always available when zipDistributable task is configured. Using lazy evaluation by wrapping these expressions in a Provider avoids that issue.

This issue was encountered in the Nix build, presumably because it uses single-threaded compilation. Combined with #1473 , this makes Processing buildable with Nix without external patches.

AI disclosure

Trees were burnt to come up with this PR since apparently that's the world we live in now. One day AI providers will at least give floor estimates of how many trees it took, but that day is not today.

I pointed Claude Opus 4.6 at the nixpkgs discussion about this problem and it correctly extracted the root cause as identified by @Stefterv in the comment chain. It correctly inferred that lazy task evaluation is required1. This was well-understood before asking Claude, but it's reassuring that it correctly reproduced these then-obvious findings.

It pointed me to the Provider.provider API (which I didn't know about for lack of familiarity with Gradle). I looked up and read the documentation for this API to understand how it works. The biggest challenge was picking the correct websearch result after realizing that provider is a function in the Provider interface (rather than a different entity), but besides that it's straightforward.

Claude produced a functional patch, however I discarded its changes and rewrote it myself with the new knowledge, though it ended up largely similar since it only affects a few lines of code and the core idea of lazy evaluation is the same. One alternative I considered is using Provider.map instead of re-wrapping providers, however there is no functional difference and it didn't help readability due to how distributable is defined.

I verified the zipDistributable target still works after running ./gradlew zipDistributable and verified that each of the steps still have the desired effect (by commenting them out individually and rerunning a clean build).


All words above this line were written and thought of by me, a human being. I physically moved a mouse and pushed keyboard buttons to open this PR. I had a ton of fun writing this text but, alas, I'm afraid the novelty of it will wear off.

Footnotes

  1. One possible alternative is to find where exactly Compose registers the createDistributable target and force this to happen before zipDistributable is evaluated, but I don't know how to figure this out and Claude didn't either.

The createDistributable task is generated by the Compose plugin, so it's not
always available when zipDistributable task is configured. Using lazy
evaluation by wrapping these expressions in a Provider avoids that issue.

This issue was encountered in the Nix build, presumably because it uses
single-threaded compilation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants