[FR] com.chaquo.python should support com.android.dynamic-feature plugin

gtomassoni commented 3 weeks ago

Chaquopy version

15.0.1

Relevant parts of your build.gradle file

apply plugin: 'com.android.dynamic-feature'
apply plugin: 'com.chaquo.python'

Describe your issue

AGP allows generating a "Dynamic Feature", a pice of app code and resource which is distributed apart from the main app.

Unfortunately, the com.chaquo.python plugin can't actually be applied to a com.android.dynamic-feature one: the above example fails with the message:

A problem occurred configuring project ':myOwnDynamicFeature'.
> Chaquopy requires one of the Android Gradle plugins. Please apply one of the following plugins to ':myOwnDynamicFeature' project: [com.android.application, com.android.library]

(besides, this message is a bit mesleading, since the com.android.dynamic-feature plugin is an "Android Gradle" one...)

The common work-around consists in referencing a module applying both com.android.library + com.chaquo.python from the one applying com.android.dynamic-feature. In example:

':df' project gradle file (the Dynamic Feature module):

apply plugin: 'com.android.dynamic-feature'

...

dependencies {
    implements project(':app')
    implements project(':chaquopy')
    ...
}

':chaquopy' project gradle file (the chaquopy module):

apply plugin: 'com.android.library'
apply plugin: 'com.chaquo.python'

...

AGP handles com.android.dynamic-feature modules in a special way, allowing them to depend on the ':app' project while limiting the code emitted in their dex files to classes not already borrowed by the app itself.

Unfortunately, this isn't the case for the ':chaquopy' project in the above example:

it can't reference the ':app' project: it would cause a circular reference, and
every dependency it references is easily going to be put in its dex file, resulting in a Type already defined error during execution of the :app:l8DexDesugarLibRelease task.

Also note that the com.chaquo.python plugin itself injects some references to external Android modules, making even more difficult to work-around doubled-defined types.

It seems to me that making the com.chaquo.python plugin "compatible" with the com.android.dynamic-feature one would be much less trouble prone than the actual work-around.

mhsmith commented 1 week ago

It seems to me that making the com.chaquo.python plugin "compatible" with the com.android.dynamic-feature one would be much less trouble prone than the actual work-around.

I agree that would be preferable, and I don't remember exactly why we don't support this.

You're correct about the general idea of the workaround, and I think you could get it working with some small changes. In fact, we have a test here which uses the same approach, with a couple of differences:

The dependencies keyword is implementation, not implements.
The app module does not directly depend on the dynamic feature module. Instead, it lists it in the dynamicFeatures setting. This should avoid the circular reference issue.

gtomassoni commented 1 week ago

"implementation", right. I messed it up in pasting an example here.

My example doesn't show an excerpt of the app module config, in which you are right that dynamicModule shall be used to refer to the df module.

What I meant to show there is that attempting to reference the app module from the chaquopy one causes a circular dependency.

I would expect that one is using the chaquopy plugin for something needing some kind of interaction with the rest of the app, which would need a reference to the app module. Which the df module supports, while the chaquopy one doesn't.

A chaquopy plugin supporting the dynamic-feature one would overcame this problem.

chaquo / chaquopy