IssueTracker

As a data point for this issue: going forward, core will likely have more dependencies on the animation primitives (from animation-core). :)

We were running into a similar circular dependency problem with animated vectors (cc Nader) - vectors live in UI but animated vectors need animation APIs.

Did we consider moving animation to be a lower group than ui? We could move the animation clock ambient to animation directly, avoiding the cyclic dependency, and also lets us use animation APIs in the ui library.

It also seems that animateContentSize makes more sense in the ui group than animation.

Re #4: Could you elaborate on what moving animation to be a lower group would look like? Is this animation or both animation and animation-core?

I assume there's a policy against having animation-core and animation in separate groups? That would solve the cicular dependency between groups.

BTW, AnimationClock is going away by Beta, although that wouldn't solve the animated vectors issue.

Re #4: Could you elaborate on what moving animation to be a lower group would look like? Is this animation or both animation and animation-core?

Sorry, I meant moving the group androidx.compose.animation 'down' - so that would be both animation and animation-core.

Currently our dependencies are something like: (we want to prevent these groups from depending on things above them)

material
foundation
animation
ui
runtime

If we swap animation and ui, and make it so that nothing in the animation group depends on ui, but allow the ui group to depend on animation, it sounds like we can fix this dependency issue, move UI related APIs like animateContentSize out of animation keeping the animation group strictly animation related, and also lets us add new APIs to ui like animated vectors since we would be able to depend directly on animation and animation-core from within ui.

From a brief look it doesn't look like this would affect much, there aren't many ui related imports in animation.

Thanks for the walk-through. It was very helpful. :) I would propose a small tweak to your suggestion: Bring animation lib into ui group, instead of moving APIs. That would allow us to animation group down.

The design intention for animation as a library was to host higher level APIs that depend on both animation-core and other modules. If we were to move the animation group down and remove animation lib's dependency on ui, and move all the APIs that depend on ui to ui, we might as well move the whole lib to ui. This way animation group would only contain animation-core (and demos and samples module for it), and it's gauranteed to not depend on anything above it. Wdyt?