Provider should have a filter method

[britter]

Expected Behavior

When dealing with a provider, I sometimes want to only use it's value if it fits a certain criteria.

val someValue: Provider<Int> = project.provider { 5 }
val even = someValue.filter { it % 2 == 0 }
require(!even.isPresent)

Current Behavior

Feature is missing

Context

I was dealing with a Provider of a list of things and I only wanted to use it in case the list contains some elements and otherwise use getOrElse to provide some default value. This is currently not easily possible due to the missing filter method.

[lptr]

This is one more case where Provider should work like Optional wherever possible.

[big-guy]

What's the expectation here?

val someValue: Property<Int>
someValue.convention(5)
val even = someValue.filter { it % 2 == 0 }
// ... somewhere else
someValue.set(4)

Is even.isPresent true or false?

[britter]

I think it should behave the same as

val someValue: Property<Int>
someValue.convention(5)
val even = someValue.map { it * 2 }
// ... somewhere else
someValue.set(4)

I don't know from the top of my head how this would behave. I think even will have the value 8, am I right?

[big-guy]

Right, I could go along with that. In your example, someValue.get() would be 8.

I was asking because Optional.filter behaves eagerly, so in my example even.isPresent would be false if Provider.filter worked like Optional.filter.

You can get close to what you're looking for with map:

val someValue: Provider<Int> = project.provider { 5 }
val even = someValue.map { it % 2 == 0 }
require(!even.get())

Only even is a Provider<Boolean> and loses the value from someValue.

I think we'd need to think more about how a filter would fit into the chain of Provider/Property because I could see it being confusing with file inputs and knowing which dependencies we need to honor.

[bamboo]

This is one more case where Provider should work like Optional wherever possible.

I assume you mean the APIs should be similar and not that providers should be eager, right?

[bamboo]

I think we'd need to think more about how a filter would fit into the chain of Provider/Property because I could see it being confusing with file inputs and knowing which dependencies we need to honor.

That doesn't sound dissimilar to the situation with orElse, particularly when the configuration cache is involved as we need to defer evaluation as much as possible.

There were talks of introducing a sort of conditional dependency (a task / work dependency that would only be activated at the last possible moment when a particular condition holds).

[lptr]

This is one more case where Provider should work like Optional wherever possible.

I assume you mean the APIs should be similar and not that providers should be eager, right?

Yes.

[big-guy]

That doesn't sound dissimilar to the situation with orElse, particularly when the configuration cache is involved as we need to defer evaluation as much as possible.

Yes, but the difference here is that you can stop once you have a producer with a value.

The dependency comes from someFile or anotherFile, depending on which one is set:

inputFile = someFile.orElse(anotherFile)

The dependency needs to be... both?

inputFile = someFile.filter { it.exists() }.orElse(anotherFile)

Maybe it's a source of footguns to have the presence of a Provider be based on the value of the Provider.

I'm trying to think of a good use case where this would be helpful...

Say you have three locations for a configuration file:

• gradle.properties
• gradle/gradle.properties
• $HOME/gradle.properties

You could have a property (pseudo):

myExt {
    propertiesFile.convention(layout.projectDirectory.file("gradle.properties"))
}

But this is missing the fallback to the other locations.

So you could do...

myExt {
    propertiesFile.convention(provider { 
        // look for each location and return the one that exists
    })
}

Or with filter:

myExt {
    propertiesFile.convention(
        layout.projectDirectory.file("gradle.properties").filter({ it.exists() })
        .orElse(layout.projectDirectory.file("gradle/gradle.properties")).filter({ it.exists() })
        .orElse(homeDir.file("gradle.properties"))
    )
}

I think the simplest thing is actually:

myExt {
    // look for each location and use the one that exists
    propertiesFile.convention(locationFound)
}

But you need to somehow record that the non-existence of some files is an input then.

[wolfs]

Having a filter method would also be one way to solve: #12388

I think it would be a better way than to use .map { null }.

[cloudshiftchris]

Using this extension function in the absence of native support:

public inline fun <reified S> Provider<S>.filter(crossinline predicate: (S) -> Boolean): Provider<S> {
    return flatMap {
        if (predicate(it)) {
            this@filter
        } else {
            Providers.notDefined()
        }
    }
}

[lptr]

FTR, once we migrate more to providers I expect more code that requires filtering like this, so delivering this feature is kind of a pre-requisite of the migration.