Open PragmaTwice opened 1 week ago
We previously had services-all
, but deciding which services to include under all
proved challenging:
hdfs
requires a JVM and libhdfs.foundationdb
requires libfoundation
.sftp
is only available on *nix
platforms.rocksdb
may require up to half an hour to compile librocksdb
if it is not already available.Additionally, this approach results in an excessively large binary.
Therefore, my current proposal is to duplicate them as demonstrated in https://github.com/apache/opendal/discussions/5206, allowing users to select the services they want during installation or deployment.
On the bindings side, this approach eliminates the need to determine which services to support; instead, we simply build them all at the time of release. This leaves the decision-making to the users.
This is also related to https://github.com/apache/opendal/issues/4939.
I'm uncertain whether it's common practice to have a libopendal_cpp_service_s3.so
that solely provides S3 configuration and builder for libopendal_cpp.so
to utilize.
🤔 Maybe we can split services into different categories?
e.g. services-all-pure-rust
, services-requires-jvm
, services-require-c-compiling
, services-requires-unix
...
So that users can easily get a approximate maximium set of services with no surprise on something like building time.
e.g.
services-all-pure-rust
,services-requires-jvm
,services-require-c-compiling
,services-requires-unix
...
I personally find this matrix difficult to maintain and stabilize.
Feature Description
Could we add a cargo feature named
services-all
to include all avaible services?So that we don't need to maintain a service list inside every bindings, e.g. C++ binding (also it seems out-dated, and change to optional features may lead to some binary release problems): https://github.com/apache/opendal/blob/32ddf46ddfbd584a83a5b5bd63c0964b05e49441/bindings/cpp/Cargo.toml#L39-L54
Problem and Solution
--
Additional Context
No response
Are you willing to contribute to the development of this feature?