Skip to content

Conversation

@baumgold
Copy link
Member

@baumgold baumgold commented Feb 8, 2024

Also add support for Sockets.InetAddr

@codecov-commenter
Copy link

codecov-commenter commented Feb 8, 2024

Codecov Report

❌ Patch coverage is 95.23810% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 87.25%. Comparing base (ac199b0) to head (57eb717).
⚠️ Report is 35 commits behind head on main.

Files with missing lines Patch % Lines
src/ArrowTypes/ext/ArrowTypesSocketsExt.jl 93.33% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #500      +/-   ##
==========================================
- Coverage   87.34%   87.25%   -0.10%     
==========================================
  Files          26       28       +2     
  Lines        3288     3280       -8     
==========================================
- Hits         2872     2862      -10     
- Misses        416      418       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@ericphanson
Copy link
Member

What happens if a table was serialized with one of these objects, but now you're loading it in a session in which e.g. UUIDs isn't loaded? I think this is probably breaking, unfortunately, since before you'd get back UUID types, whereas now you have to change your code to load UUIDs to get it.

@baumgold
Copy link
Member Author

baumgold commented Feb 8, 2024

What happens if a table was serialized with one of these objects, but now you're loading it in a session in which e.g. UUIDs isn't loaded? I think this is probably breaking, unfortunately, since before you'd get back UUID types, whereas now you have to change your code to load UUIDs to get it.

That's a valid point, thanks for bringing it up. Do you think it's worth continuing with this change but bump major rather than minor? Or should we abandon this change for now?

@ericphanson
Copy link
Member

These are pretty light packages, and are in the sysimage anyway until v1.11, so to me it doesn’t feel worth all the compat bumps it will cause. I think it’s worth waiting until there’s other reasons for a breaking change, or some big reason why having them is causing problems.

@baumgold
Copy link
Member Author

baumgold commented Feb 9, 2024

Sounds good. I'll put this PR on hold for now. Thanks for the feedback.

@ericphanson ericphanson removed their request for review February 12, 2024 12:49

[compat]
julia = "1.0"
julia = "1.9"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not keep the existing Julia version compat and do this instead? https://pkgdocs.julialang.org/v1/creating-packages/#Transition-from-normal-dependency-to-extension

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants