Hello everyone,
When I was running the RCK against Lakekeeper, I noticed that RCK verifies not
only the exception type but also the error message. RCK verifies the messages
as they are written in the Java implementation, and since Lakekeeper uses
iceberg-rust, we have different error messages [
+1 (non-binding)
- verified signature and checksum
- verified license check- ran install and some manual tests in python 3.11
André Anastácio
On Saturday, November 16th, 2024 at 4:08 AM, Honah J. wrote:
> +1 (binding)
>
> Thanks for running the release!
>
> - Verified signatures/checksum/licen
+1 (non-binding)
- verified signature and checksum
- verified license check
- ran install and some manual tests in python 3.11
André Anastácio
On Sunday, November 10th, 2024 at 5:02 AM, Honah J. wrote:
> +1 (binding)
>
> Thanks for running the release!
>
> - Verified signatures/checksum/licens
amental need is not addressed in Python ecosystem.
>
> Best
> Piotr
>
> On Tue, 15 Oct 2024 at 01:53, André Luis Anastácio
> wrote:
>
>> Thank you Piotr Findeisen and Sung Yun, for your insights.
>>
>> I did a quick search and didn’t find anything more &
that are disabled or enabled means there are two flows of the
>> code (assert expression can have side effects!), how do you test for that?
>> Having one flow is a simplification.
>> This is a reasoning for Java codebase, but I don't think arguments are
>> language-specific,
Hello Everyone,
I would like to open a discussion about using "assert" in some functions to
promote a more defensive programming approach, ensuring that certain
assumptions in our code are always validated.
The intention here is to propose a recommendation, not a strict rule. What are
your tho
- validated signatures and checksums
- checked license
- ran tests and test-coverage with Python 3.9.12
+1 (non-binding)
André Anastácio
On Tuesday, August 13th, 2024 at 10:19 PM, Sung Yun wrote:
> Hi Everyone,
>
> I propose that we release the following RC as the official PyIceberg 0.7.1
>
r something similar; I
>> haven't given it much thought yet.
>>
>> FileIO is now a widely shared design across different language
>> implementations, and we have built a mature mechanism to allow users to
>> implement and provide their own FileIO. By adding a new AP
t in there, there will be
> a strong need to do that.
>
> Orphan files is quite a resource-intensive operation since it requires
> listing all the files under the location, and comparing this with all the
> files in the metadata (I was hoping to leverage the metadata tables for that).
Hello everyone,
I’ve been studying the Java implementation of orphan file removal to replicate
it in PyIceberg. During this process, I noticed a key difference: in Java, we
use the Hadoop Filesystem[1], while in PyIceberg, we use the Filesystem
provided by FileIO[2][3].
Currently, we support t
- validated signatures and checksums
- checked license
- ran tests and test-coverage with Python 3.9.12
+1 (non-binding)
André Anastácio
On Friday, August 9th, 2024 at 4:30 PM, Sung Yun wrote:
> Hi Everyone,
>
> I propose that we release the following RC as the official PyIceberg 0.7.1
> rel
mit](https://github.com/apache/iceberg-python/pull/1017)
>
> Kind regards,
> Fokko
>
> Op di 6 aug 2024 om 21:17 schreef André Luis Anastácio
> :
>
>> What do you think about adding the fix that excludes PyIceberg support for
>> Python 3.9.7 in the 0.7.1 release?[
What do you think about adding the fix that excludes PyIceberg support for
Python 3.9.7 in the 0.7.1 release?[1] It already doesn't work, so this is just
to avoid any new issues.
- [1]: https://github.com/apache/iceberg-python/pull/526
André Anastácio
On Tuesday, August 6th, 2024 at 4:06 PM,
+1 (non-binding)
- Validated signatures / checksums
- Checked license
- Ran some code examples in Python 3.12
André Anastácio
On Monday, July 29th, 2024 at 2:42 PM, Kevin Liu wrote:
> +1 (non-binding)
> Verified signatures/checksums/license. Ran unit and integration tests. Logs
> are attache
14 matches
Mail list logo
