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
