Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

migrate ArrowTypes code that depends on Sockets and UUIDs to extensions #500

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

baumgold
Copy link
Member

@baumgold baumgold commented Feb 8, 2024

Also add support for Sockets.InetAddr

@codecov-commenter
Copy link

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (ac199b0) 87.34% compared to head (57eb717) 87.24%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #500      +/-   ##
==========================================
- Coverage   87.34%   87.24%   -0.11%     
==========================================
  Files          26       28       +2     
  Lines        3288     3276      -12     
==========================================
- Hits         2872     2858      -14     
- Misses        416      418       +2     

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

@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