Re: [I] A more robust way to deprecate APIs [iceberg-python]

2024-11-23 Thread via GitHub
ndrluis commented on issue #1330: URL: https://github.com/apache/iceberg-python/issues/1330#issuecomment-2495711478 One new aspect introduced with this Conda deprecation code is the concept of a pending deprecation process. I think that when we release version 1.0, we will need to allocate

Re: [I] A more robust way to deprecate APIs [iceberg-python]

2024-11-20 Thread via GitHub
ndrluis commented on issue #1330: URL: https://github.com/apache/iceberg-python/issues/1330#issuecomment-2488482355 @kevinjqliu Yes, it refers to the call site. The ‘argparse.Action’ example in the documentation demonstrates this. @Fokko I agree with using a library, but the depr

Re: [I] A more robust way to deprecate APIs [iceberg-python]

2024-11-19 Thread via GitHub
Fokko commented on issue #1330: URL: https://github.com/apache/iceberg-python/issues/1330#issuecomment-2487793689 Hey @ndrluis thanks for bringing this up! Are you suggesting to copy the code into our codebase? I always favor reusing an existing library instead of reinventing the wheel. I

Re: [I] A more robust way to deprecate APIs [iceberg-python]

2024-11-19 Thread via GitHub
kevinjqliu commented on issue #1330: URL: https://github.com/apache/iceberg-python/issues/1330#issuecomment-2487482903 thanks for doing the research! I like this approach. do you know if the deprecation message includes the call site or stack trace? for example, in #1336, it would be he