IssueTracker

The ToT dependency was coming from compose:test-utils. Jeremy raised aosp/2254837 to pin this to a prebuilt.

Alternatively, we could have added explicit androidTestImplementation dependencies on ToT to ensure it's available during dependency resolution.

TL;DR If we express a constraint on androidx.thing:thing:$TOT_VERSION which maps to the tip-of-tree version for :thing:thing, then any occurrence of androidx.thing:thing:$VERSION where the constraint is present must also include :thing:thing somewhere in the transitive dependencies.

My understanding of this issue is:

• Project A's library code depends on prebuilt B.

• Project A's test depends on prebuilt B and also library C.

• Library C declares a constraint saying that B must be the same version as Library C.

• When resolving dependencies for Project A's tests, these tests depend on prebuilt B and library C, so library C's dependency information is also considered.

• Library C says it requires B of the same version.

• To reconcile:

  • these requirements:
    • the dependency on prebuilt B
    • the constraint for B to match the version of C
  • Gradle looks for a prebuilt of B with version matching C.

• No prebuilt of B exists with the same version matching Library C, so Gradle fails to resolve the dependency.

Is this right?

The request in b/146802533 is that libraries should publish this constraint information (rather than that Gradle should know how to automatically update prebuilt dependencies into project dependencies), so I think this issue is probably different

No prebuilt of B exists with the same version matching the prebuilt of C, so Gradle fails to resolve the dependency.

Just to make sure we're aligned, this should read "library C" rather than prebuilt? It's library C (e.g. project(C) with version $X) that expresses a constraint on prebuilt B at version $X.

Assuming we're aligned...

Yes however if library B (e.g. project("B")) exists in the set of dependencies and its version matches C, then Gradle will successfully resolve the dependency by "upgrading" prebuilt B to library B.

No prebuilt of B exists with the same version matching the prebuilt of C, so Gradle fails to resolve the dependency.

Just to make sure we're aligned, this should read "library C" rather than prebuilt? It's library C (e.g. project(C) with version $X) that expresses a constraint on prebuilt B at version $X.

Yes! Fixed, thanks

The request in b/146802533 is that libraries should publish this constraint information (rather than that Gradle should know how to automatically update prebuilt dependencies into project dependencies), so I think this issue is probably different

Slightly different. Fixing b/146802533 will necessarily involve fixing this issue, since emitting constraints into all projects will cause this issue.

Given that this was caused by tests using different dependency versions than the library's runtime dependencies, though, maybe this is broken-as-intended? The fix that Jeremy implemented was to pin the tests to the same version.

Marking as Fixed even though the general problem can still occur. Unclear that we need a systemic fix.

The documentation suggests that setname is supported, though I am still seeing the same error from the original post on the region: us-central1.

The documentation is for the Cluser version of Redis, not for standalone instances. It would seem that the standalone instances still do not support setting a client name.

dup of https://issuetracker.google.com/issues/169419385