This message was deleted.

Can't you use

this.getProject().getGradle().getTaskGraph()

from your

@TaskAction

?

til (I must say my plugins are simple enough to never have stumbled on those restrictions)

huh, I tried again, and it works now... (I probably picked a too complex test to experiment on)

@get:Internal // does not affect outputs
internal abstract val hasTask: Property<Boolean>
init {
    hasTask.convention(project.provider { project.gradle.taskGraph.hasTask(":myTask") })
}
@TaskAction fun f() { val hasTask = hasTask.get() ... }

I think using

project

inside task is discouraged

I kept it inside, because it's totally internal, like a private function. Not an input.

you can provide it in the constructor as implementation detail too

(It doesn't matter where you wire it though, the problem would be the same even if it was captured in a lambda's anonymous inner class)

you can do

project.register<MyTask>("myTask", provider<Boolean> { project.hasTaskWhatever() })

open class MyTask @Inject constructor(private val hasTaskWhatever: Provider<Boolean>) : DefaultTask()

yeah, but when I mean implementation detail, I mean really internal to the task, if I expose it in the public constructor it puts the burden of creation to all users of the task, ending up with duplicate code. For input/output wiring, yes I agree that

project.register<T>("name") { prop.convention/set(...) }

is the best option, because those things change between usages.