Why does Gradle insist on creating all the directories that I specify as output directories of a task? I have a task where one instance may put some files there, and another instance may not, but it’s difficult for me to know in advance which one will use which directories. So I specify the union set of all these directories as outputs. But now I have to tolerate all these empty output directories “helpfully” created by Gradle sitting around polluting my file system view…

I actually like this behaviour. For snapshotting purposes, the directory should always be present.

Why should it always be present?

The outputs are pretty much an implementation detail. Ultimately, I wish Gradle allocates the path automatically as well

Well in my case that wouldn’t work because the outputs are decided by the app my task is running.

It's mostly about API design

not just API, user experience too

Is there even

@Optional

for outputs?

that would have different semantics

The parallel I make is nullability. I want things to be never nullable because it's less

if

s in my code. Similarly I want some consistency in the tasks inputs/outputs.

It’s always nice if it works that way, yes, but I’m creating Gradle tasks to encapsulate/wrap an existing application that I can’t modify to 100 % fit this idea. In many other ways Gradle has been excellently flexible and that’s why I chose it and I’m happy with my choice, but this is an annoyance, even though minor.

Yea that's the thing, I want Gradle to stop being flexible and give me so many footguns 😂 Just be opinionated about tasks and make everything cacheable by default, using relative path sensitivity, enforce non-overlapping outputs, etc...

That’s what #C06JG95HREY is going to be, I believe

To some extent yes although it's mostly the frontend from what I have seen

You could configure the various directories as

@Internal

properties and have an output property whose value is computed by the task depending on what it will do / have to do.

I don't think you can calculate the output property at task execution time. That would not work with up-front checking up-to-date state.

hmm that could be a nice workaround but wouldn’t it mess with Gradle’s internal state or something? after all, it created those directories for some reason so it probably assumes they will exist?

As far as I remember, it shouldn't be a problem. And having a quick look at the Gradle code, I think the creation is not conditional, so deleting them might indeed be the only way. You'll see whether it complains then when snapshotting the outputs after the task executed. 🙂

Just tried it, it works, and is compatible with configuration cache:

abstract class MyTask : DefaultTask() {
    @get:Internal
    abstract val fooDir: DirectoryProperty
    @get:Internal
    abstract val barDir: DirectoryProperty
    @get:Input
    abstract val useFoo: Property<Boolean>
    @get:OutputDirectory
    val outputDirectory: DirectoryProperty
        get() = if (useFoo.getOrElse(false)) fooDir else barDir
    @TaskAction
    fun run() {}
}

tasks {
    register<MyTask>("fooOrBar") {
        fooDir = layout.buildDirectory.dir("foo")
        barDir = layout.buildDirectory.dir("bar")
        useFoo = false
    }
}

Yeah, that is not calculated at execution time but configuration time.

right, my problem is, this ‘useFoo’ is not something the users specify in Gradle, it’s something that’s specified somewhere deep in those files that the task is processing.

Well, this works too:

abstract class MyTask @Inject constructor(
    private val providers: ProviderFactory
): DefaultTask() {
    @get:Internal
    abstract val fooDir: DirectoryProperty
    @get:Internal
    abstract val barDir: DirectoryProperty
    @get:InputFile
    abstract val inputFile: RegularFileProperty
    @get:Internal
    val inputFileContent: String by lazy { inputFile.get().asFile.readText() }
    @get:OutputDirectory
    val outputDirectory: Provider<Directory>
        get() = providers.provider { if (inputFileContent == "foo") fooDir.get() else barDir.get() }
    @TaskAction
    fun run() {}
}

tasks {
    register<MyTask>("fooOrBar") {
        fooDir = layout.buildDirectory.dir("foo")
        barDir = layout.buildDirectory.dir("bar")
        inputFile = layout.projectDirectory.file("input")
    }
}

Of course determining whether you use

fooDir

or

barDir

needs to be relatively lightweight, as you pay that price every time, to compute whether the task is up-to-date or not, to decide whether to run it or not