The current state-of-the-art for image loading in Compose apps is the Accompanist library, which provides a Compose wrapper around Coil and Glide APIs. We still use Picasso heavily internally though, so it might make sense to add Compose support directly to Picasso, at least if it's not too much trouble.

Open questions

I don't have strong opinions on the API yet, but there are some questions that we need to answer:

1. Should we even bother? Or just start using Coil instead? Coil is a great library, it provides (nearly all, and even some more) the features of Picasso, it's extensible, etc. There's also Kamel which even supports Kotlin multiplatform.
2. Assuming we want to support it, should it ship as part of the core Picasso artifact or a separate, compose-specific support artifact?
3. Some of the Picasso APIs expose drawables. Drawables are not support in Compose, so how should the Compose integration handle them?
   • The simplest thing to do would probably be just host an Android View inside the composition to render drawables.
   • Accompanist actually provides an internal-only implementation that even supports animated drawables. Not sure we want to maintain that much code.
4. How much of the existing API should be reused? E.g. should we provide a Composable function that takes all the parameters that can be configured on a RequestCreator, or some way to just provide a RequestCreator to the composable? Since RequestCreator is a mutable, non-compose-stable type, we can't just pass a RequestCreator instance to a composable function.
5. Should we provide error/placeholder overloads that take composable functions?
6. Should the composable require an explicit Picasso instance to be passed in, or should we allow one to be provided through a CompositionLocal? This question might not matter depending on the answer to (4).

There are probably more questions to be asked, feel free to edit this description or add them in the comments.