feat(binding/dart): add pubspec info

[asukaminato0721]

Which issue does this PR close?

part of #5722 .

Rationale for this change

prepare for the publish

What changes are included in this PR?

Are there any user-facing changes?

user may able to install it through https://pub.dev/

ref

1. How can I use dart ffi properly in a pub package?
2. https://kazlauskas.dev/blog/publishing-new-flutter-package/

Seems that user need to install rust and build the package themselves.

[Xuanwo]

Since we need to build our rust core first, I assume we need to generate artifacts in CI and then publish them?

[asukaminato0721]

Did some research, and an issue. fzyzcjy/flutter_rust_bridge#2624 (comment)

but it will need yet another tool called cargokit https://github.com/irondash/cargokit/blob/main/docs/precompiled_binaries.md

So I guess just let the user manually put the prebuild .so to the directory will be simpler.

in CI, build it, upload it, and let user put them into the folder.

And if dart run xxx just work, rust code is just for generate the dylib, so in theory we don't need to publish them.(Not a big deal)

[Xuanwo]

Hi, my expectations for OpenDAL Dart are that users can use it just like a native Dart package:

name: my_app

dependencies:
  opendal: ^0.1.0

They shouldn't need to install rustup or even be aware of rust. This is how our Python and Node.js bindings work.

Can we implement the same approach for dart?

[asukaminato0721]

Can we implement the same approach for dart?

pyo3 build wheels and upload them to pypi, user download them based on their py version and system.

napi-rs upload all the binaries to different packages.

so in theory dart will need to similar things.

something like this: https://github.com/dart-archive/tflite_native/tree/master/lib/src/blobs

[Xuanwo]

so in theory dart will need to similar things.

something like this: https://github.com/dart-archive/tflite_native/tree/master/lib/src/blobs

Yep, that's the thing we have to figure out. Can we upload it to pub.dev directly? Or we have to store it in a git repo like golang?

[asukaminato0721]

Can we upload it to pub.dev directly?

I find this https://pub.dev/packages/tflite_native/install

so we can. One way I guess is to build all version of so/dll, then put them to repo in CI, pub it to pub.dev (is this possible?)

So we don't need to put binary in repo.

[Xuanwo]

so we can. One way I guess is to build all version of so/dll, then put them to repo in CI, pub it to pub.dev (is this possible?)

So we don't need to put binary in repo.

That will be really nice!

[asukaminato0721]

it's possible lol. I tested it on another simpler repo.

open-spaced-repetition/fsrs-rs-dart#17

[asukaminato0721]

./target/release:
libopendal_dart.dylib
libopendal_dart.so
opendal_dart.dll

ok, it works.

The final step is "pub it to pub.dev", which require the "opendal" account I guess.

[Xuanwo]

libopendal_dart.dylib
libopendal_dart.so
opendal_dart.dll

We need to give this more thought. For example, Linux x86_64 and Linux ARM will require different artifacts. We can implement them in the future, but we should choose the right naming pattern now.

The final step is "pub it to pub.dev", which require the "opendal" account I guess.

We need to build 0.1.0-rc.1 first and then use CI to perform the publish.

[Xuanwo]

Other looks good to me, I think it's fine to start with a build only actions.

[Xuanwo]

We should build only for RC tags and publish only for formal tags.

[asukaminato0721]

how to modify it?

[Xuanwo]

We need something like

opendal/.github/workflows/release_python.yml

Line 117 in b8e778c

if: ${{ startsWith(github.ref, 'refs/tags/') && contains(github.ref, '-') }}

We can implement in next PR.

[asukaminato0721]

We need to give this more thought. For example, Linux x86_64 and Linux ARM will require different artifacts. We can implement them in the future, but we should choose the right naming pattern now.

Idea: cargo build --target will put the binary to a sub folder, name follows https://doc.rust-lang.org/beta/rustc/platform-support.html

and fzyzcjy/flutter_rust_bridge#2644 (comment) says we can input the dll path.

so now each arch will have it's own path.

[asukaminato0721]

from the output

./target/release:
aarch64-apple-darwin
aarch64-unknown-linux-gnu
x86_64-pc-windows-msvc
x86_64-unknown-linux-gnu

./target/release/aarch64-apple-darwin:
libopendal_dart.dylib

./target/release/aarch64-unknown-linux-gnu:
libopendal_dart.so

./target/release/x86_64-pc-windows-msvc:
opendal_dart.dll

./target/release/x86_64-unknown-linux-gnu:
libopendal_dart.so

now all lib at their unique position.

[Xuanwo]

Thank you, looks great!