My initial comment on this is that neither Go nor Rust, to my knowledge, support dynamic loading in this way. So formalization of rs-, cpp- or go- prefixes like this wouldn't be useful in any meaningful way as they would need to be linked in ahead of time for it to work.
There are probably very hacky ways to support it, but I don't think it would be a good idea to support this as a universal idea for multiple languages at the spec level. --Matt On Fri, Jan 24, 2025, 1:02 AM Gang Wu <ust...@gmail.com> wrote: > Generally it makes sense to define separate language-specific > configurations. > > I think we need to think about the following items: > 1. Is it python-specific to add the prefix? Should Rust/Go be -rs/-go as > the convention? > 2. Which part of the spec is the best place to describe this? It seems > that we need to include all affected configurations and add guidelines for > future ones. > > Best, > Gang > > On Thu, Jan 23, 2025 at 3:58 AM Kevin Liu <kevinjq...@apache.org> wrote: > >> Hi everyone, >> >> I’d like to open a discussion on the naming scheme for configuration >> parameters across different languages. >> >> While working on the LocationProvider implementation in PyIceberg (#1452 >> <https://github.com/apache/iceberg-python/pull/1452>), we encountered a >> challenge with naming configuration parameters for custom implementations. >> In the Java library, the parameter `write.location-provider.impl` >> <https://github.com/apache/iceberg/blob/be6e9daf8901cdee63197e77fcf95624bb694f39/core/src/main/java/org/apache/iceberg/TableProperties.java#L257> >> is used to configure a custom LocationProvider implementation. However, for >> cross-language compatibility, we couldn’t reuse this parameter directly. >> Configuration parameters defined in one language are not automatically >> compatible with others. >> >> To address this in PyIceberg, we chose to use >> `write.py-location-provider.impl` as the parameter name. This approach >> aligns with PyIceberg’s existing naming convention for custom >> implementations, such as `py-catalog-impl` (vs. `catalog-impl` >> <https://github.com/apache/iceberg/blob/be6e9daf8901cdee63197e77fcf95624bb694f39/core/src/main/java/org/apache/iceberg/CatalogProperties.java#L27>) >> for custom catalog implementations and `py-io-impl` (vs. `io-impl` >> <https://github.com/apache/iceberg/blob/be6e9daf8901cdee63197e77fcf95624bb694f39/core/src/main/java/org/apache/iceberg/io/FileIOParser.java#L32>) >> for custom FileIO implementations. >> >> I’d like to propose formalizing the use of the `py-` prefix for >> Python-specific configurations and extending this naming scheme to other >> languages, such as Rust, Go, and C++. This would create a consistent, >> predictable pattern for language-specific configuration parameters across >> the project. >> >> Looking forward to hearing your thoughts! >> >> Best, >> Kevin Liu >> >>
