Use lazy evaluation for dependencies of the zipDistributable task#1474
Open
neobrain wants to merge 1 commit intoprocessing:mainfrom
Open
Use lazy evaluation for dependencies of the zipDistributable task#1474neobrain wants to merge 1 commit intoprocessing:mainfrom
neobrain wants to merge 1 commit intoprocessing:mainfrom
Conversation
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.
Stefterv
approved these changes
Mar 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
provideris a function in theProviderinterface (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.mapinstead of re-wrapping providers, however there is no functional difference and it didn't help readability due to howdistributableis defined.I verified the zipDistributable target still works after running
./gradlew zipDistributableand 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
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. ↩