During the release process, the OCaml bindings for Opendal encountered some issues, one of which is as follows. Opam, OCaml's package manager, builds from the project's root directory. This requires the presence of files such as opendal.opam and dune-project in the project's root directory. However, this is not suitable for the Opendal project because these files are specific to just one binding used by Opendal.
A feasible solution currently is to replace opendal = { path = "../../core" } with a specific version in the Cargo.toml file located in binding/ocaml. This allows the binding to be built independently. Consequently, during the release, we can package this binding separately as apache-opendal-$release_version-binding-ocaml-src.tar.gz, thus circumventing issues with Opam builds.
However, this approach introduces challenges, such as coordinating development between the binding and the core during ongoing development. I would like to hear everyone's thoughts on how to address these challenges.
During the release process, the
OCaml bindingsfor Opendal encountered some issues, one of which is as follows.Opam, OCaml's package manager, builds from the project's root directory. This requires the presence of files such asopendal.opamanddune-projectin the project's root directory. However, this is not suitable for the Opendal project because these files are specific to just one binding used by Opendal.A feasible solution currently is to replace
opendal = { path = "../../core" }with a specific version in theCargo.tomlfile located inbinding/ocaml. This allows the binding to be built independently. Consequently, during the release, we can package this binding separately asapache-opendal-$release_version-binding-ocaml-src.tar.gz, thus circumventing issues with Opam builds.However, this approach introduces challenges, such as coordinating development between the binding and the core during ongoing development. I would like to hear everyone's thoughts on how to address these challenges.