fzyzcjy / flutter_rust_bridge

Flutter/Dart <-> Rust binding generator, feature-rich, but seamless and simple.
https://fzyzcjy.github.io/flutter_rust_bridge/
MIT License
3.74k stars 267 forks source link

[Question] How can we continue with melos splitting package setup with packages also published to pub.dev? #2177

Open AlexV525 opened 6 days ago

AlexV525 commented 6 days ago

Is your feature request related to a problem? Please describe.

We have followed the construction before to separate packages and managed by Melos. A pseudo structure is:

> packages/
--> plugin_flutter/
----> android/
----> cargokit/
----> ios/
--> plugin_dart/
----> lib/
----> tests/
--> plugin_ffi/
----> lib/
----> rust/
------> rust_package_main/
------> rust_package_other_1/
------> rust_package_other_2/

While the cargokit configuration can use a relative path to define the manifest directory, it seems impossible for the configuration to find the correct target if these packages are used as a hosted package.

For example, plugin_flutter and plugin_ffi are both published to pub.dev. If we configured the manifestDir to `"../../plugin_ffi/rust/rust_package_main", how would libraries generate properly?

Describe the solution you'd like We should find a solid solution to targeting the rust directory.

Describe alternatives you've considered None.

Additional context None.

fzyzcjy commented 6 days ago

I guess this may not be possible if structure is like that, since cargokit can only compile rust code within that same package.

However, what about

> packages/
--> plugin_flutter/
----> android/
----> cargokit/
----> ios/
----> rust/ (a symlink to real rust folder)
--> plugin_dart/
----> lib/
----> tests/
----> rust/ (a symlink to real rust folder)
--> rust/
----> rust_package_main/
----> rust_package_other_1/
----> rust_package_other_2/

EDIT: Hmm that's also not ideal if there are code that is to be shared between dart and flutter package.

Then what about provide precompiled binaries to users instead of bundle rust source code.

In the long term, the Dart "native assets" feature will be very helpful, since we will only need a single build.dart and done for both dart and flutter.

EDIT: Maybe another way is:

> packages/
--> plugin_flutter/
----> android/
----> cargokit/
----> ios/
----> rust/ (a symlink to real rust folder)
--> plugin_dart/
----> lib/
----> tests/
--> plugin_ffi/
----> lib/
----> rust/ (a symlink to real rust folder)
--> rust/
----> rust_package_main/
----> rust_package_other_1/
----> rust_package_other_2/

Then cargokit can find the rust code (which is a symlink, but when published to pub.dev it is copied and bundled)

Btw could you please explain dependency relationship between the 3 packages? I am not sure and maybe my guess above is wrong.

AlexV525 commented 6 days ago

Btw could you please explain dependency relationship between the 3 packages? I am not sure and maybe my guess above is wrong.

The plugin_flutter is for Flutter usages, and plugin_dart is for pure Dart usages.

fzyzcjy commented 6 days ago

Then I guess maybe we can

> packages/
--> plugin_flutter/
----> android/
----> cargokit/
----> ios/
----> rust/ (a symlink to real rust folder)
--> plugin_dart/
----> lib/
----> tests/
----> rust/ (a symlink to real rust folder)
--> plugin_ffi/
----> lib/
----> rust/ (a symlink to real rust folder)
--> rust/
----> rust_package_main/
----> rust_package_other_1/
----> rust_package_other_2/

and let cargokit etc point to sibling rust symlink folder to compile it.

AlexV525 commented 6 days ago

Hmm, could be a solution.