Open xxchan opened 2 months ago
+1 for this, which helps to decipher in compatible types with same name. cc @Xuanwo What do you think?
-0 on this.
I'm not in favor of re-exporting other crates based on my own experience. However, as @xxchan mentioned, there aren't many drawbacks, so I'm okay if someone wants to add it.
One case I think this helps is that when another project uses both arrow and iceberg, but with different versions, just as the case in the issue. When you pass them as arguments, you may see quite confusing compiler error like arrow::RecordBatch is not arrow::RecordBatch
, since rust treat types from diffrent crate versions as different types. A more detailed example could be found here. Re-exporting makes things easier to understand.
Hi, I propose to re-export arrow types in iceberg. Want to hear your opinions @liurenjie1024 @Xuanwo
Rationale
When a crate uses a dependency's type in the public API, it would be better to re-export the dependency.
The largest benefit is ease of handling multiple versions:
In this case, if we want to pass
arrow_array::RecordBatch
toiceberg
, we have to do something like this:and then pass
arrow_array_for_arrow_udf::RecordBatch
toiceberg
. Ificeberg
re-export it likeiceberg::arrow::RecordBatch
, then we don't need to do so.Note: This assumes that multiple versions are to some extent unavoidable. It won't help if we want to pass arrow 50 data to arrow 52 data. But it's more like some part of the code only want to pass data to
iceberg
without affecting other parts of the code that uses arrow 50.Finally, I don't think there are any drawbacks to re-export
arrow
iniceberg
.More discussion about this problem:
delta-rs
re-exportarrow_array::RecordBatch
, highly similar to us here)