ProviderFactory.fromBuildable(buildable: Buildable): Provider<Void> for using Buildable as a regular Provider

[vlsi]

Expected Behavior

There should be a way to express "dependency on Buildable" in user code (e.g. in domain objects).
For instance, something like providers.fromBuildable(buildable).map { ... }...

Sample use case is to consume org.gradle.api.publish.PublicationArtifact which implements Buildable and exposes getFile(): File method:

gradle/subprojects/publish/src/main/java/org/gradle/api/publish/PublicationArtifact.java

Lines 28 to 39 in f632e1a

	public interface PublicationArtifact extends Buildable {
	/**
	* The actual file contents to publish.
	*/
	File getFile();
	/**
	* Registers some tasks which build this artifact.
	*
	* @param tasks The tasks. These are evaluated as per {@link org.gradle.api.Task#dependsOn(Object...)}.
	*/
	void builtBy(Object... tasks);

Well, of course, it would be nice if PublicationArtifact exposed something like getRegularFile(): Property<RegularFile> that included the dependency automatically, however being able to convert Buildable to Provider<Void> would probably be nice.

Current Behavior

Currently, Property<Buildable> is not compatible with the configuration cache.

// Configuration cache is not supported yet since
// Task `:sigstoreSignMavenPublication` of type `dev.sigstore.sign.tasks.SigstoreSignFilesTask`:
// cannot serialize object of type 'org.gradle.api.publish.maven.tasks.GenerateMavenPom',
// a subtype of 'org.gradle.api.Task', as these are not supported with the configuration cache.

Context

I'm trying to support the configuration cache for Sigstore Gradle plugin:

• https://github.com/vlsi/sigstore-gradle/blob/2b90947b21702fd2287d8d8a10a55da339cdd771/sigstore-sign-base-plugin/src/main/kotlin/dev/sigstore/sign/SigstoreSignature.kt#L40-L41
• https://github.com/vlsi/sigstore-gradle/blob/2b90947b21702fd2287d8d8a10a55da339cdd771/sigstore-sign-base-plugin/src/main/kotlin/dev/sigstore/sign/SigstoreSignExtension.kt#L85

[vlsi]

I've been able to workaround the case via using a "private" ConfigurableFileCollection.
I store no files in the collection, however, I use it's ConfigurableFileCollection#builtBy methods to add Buildable dependencies.

Here's my workaround: vlsi/sigstore-gradle@b9682e7#diff-3ffe84973b634fa46d701efd6468c52ee99d2e79e5ba0fec62306c6ec948a099R42-R65

[jbartok]

That's not something we should do. We should instead expose the right types on those API, like the RegularFile property in your example.

[vlsi]

That is fine with me.
However, I thought the number of APIs that expose Buildable is huge, and it would take a LOT to fix all of them.

[vlsi]

For instance, what if I want to create a property based on FileCollection (e.g. take "task dependencies" from there), and Provider.map it to some other type (e.g. number of files within the collection)?

Having something to embed "task dependency" into a provider would be helpful in my point of view.
Another possibility is to add builtBy(...) into the Property, however, that might be too much.

[eskatos]

For FileCollection you can use FileCollection#elements which returns a Provider<Set<FileSystemLocation>>.
See https://docs.gradle.org/current/javadoc/org/gradle/api/file/FileCollection.html#getElements--

[vlsi]

@eskatos , I'm glad you mentioned FileCollection#elements as it enabled me to workaround mustRunAfter(configuration) issue: #21962 (comment) :)