Skip to content

Remove CoursierModule#mapDependencies #5070

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

alexarchambault
Copy link
Collaborator

This PR removes CoursierModule#mapDependencies altogether, and uses CoursierModule#resolutionParams instead. mapDependencies is hack that the coursier API allows, but it's too powerful IMO. A benefit of using resolution params instead is that almost anything done via resolution params can be done via the coursier command-line, which is handy to debug things.

Copy link
Member

@lihaoyi lihaoyi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine to me I guess, but would be would be good to have a slightly longer explanation in the PR description of what the change means. What kind of code would be going away? What does the replacement look like?

@lefou
Copy link
Member

lefou commented May 6, 2025

As we have users of this API, a discussion how to replace it, would be nice. E.g. my main usage is:

  • Replace some transitive dependencies (change coordinates, e.g. replace some logging impl with a different impl; switch from non-osgi to separately released osgi artifact)
  • Bump or enforce transitive versions

lihaoyi pushed a commit that referenced this pull request May 15, 2025
## Summary

Following @alexarchambault work on
#4626 I've done some dependency
cleanup + others . The aim is to remove as many dependency management
workarounds from the past android attempts as possible and rely solely
on coursier

## Dependency cleanup

I have managed to cleanup most of the examples but I've introduced some
small workarounds in two places:
1. Screenshot testing: This is kind of a special case, first even in AGP
it's super experimental, and I had to use the defaultResolver to get the
runtime dependencies in the tree and put them in the screenshot
classpath
2. In the hilt example, I had to add a few dependencies by hand that are
marked as runtime only by hand (see below the runtime section). On the
good news I've removed the mapDependencies workaround.

## Runtime management

- I have introduced some scaffolding to later separate the runtime
classpath from the compile time in an effort to have a more flexible way
of choosing what to add in the APK. I'm not entirely convinced this is
the way to go, it only kind of worked in the screenshot testing and unit
testing. I'd like to have it merged for now for later experimentation
and if it doesn't get me anywhere I'll remove it.
- I've introduced 2 new methods for managing android dependencies on top
of the resolvedMvnDeps and resolvedRunMvnDeps for further flexibility,
my plan is to allow for further experimentation with coursier (I've
already tried locally some configurations by overriding resolvedMvnDeps
for example) but haven't found the ideal way for reducing the need to
(re)declare some runtime dependencies.

## Android resources

I've separated the /resources from /res using `androidResources` and did
some housekeeping around classpath resolution.

## Things left to do

I think I'll need some help from @alexarchambault , I saw this PR
#5070, and I'd like some advice
on an alternative approach to use endorse strict versions

## Test hardening

- Hilt example now installs the app and runs the activity, to make sure
that things are working further than dex packaging
- Kotlin compose example also has the same test arrangement to make sure
the apk is installable and runnable

## R8 fixes

On experimenting with 2-compose example, I've found that main dex args
are not available for compiling against Api level 21 (so building the
compose example with R8 breaks). I removed it for now, it's not a good
default, might revisit later on on adding it for older versions of
android
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants