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

Support --all-features again #708

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

Conversation

nicklan
Copy link
Collaborator

@nicklan nicklan commented Feb 21, 2025

What changes are proposed in this pull request?

If both arrow_53 and arrow_54 are specified, just use arrow_53

Also update the README for the new situation.

I'd like to emit a warning if more than one feature is enabled, but there is no compiler_warning!. See here for some discussion. If reviewers feel the must_use hack would be worth it, I can add it.

Copy link

codecov bot commented Feb 21, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.03%. Comparing base (ca18e7f) to head (22394c8).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #708      +/-   ##
==========================================
- Coverage   84.36%   84.03%   -0.33%     
==========================================
  Files          75       77       +2     
  Lines       17654    18063     +409     
  Branches    17654    18063     +409     
==========================================
+ Hits        14893    15179     +286     
- Misses       2052     2165     +113     
- Partials      709      719      +10     

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

@github-actions github-actions bot added the breaking-change Change that will require a version bump label Feb 21, 2025
@nicklan nicklan changed the title Attempt to fix semvar check due to new feature flags Support --all-features again Feb 21, 2025
@nicklan nicklan marked this pull request as ready for review February 21, 2025 00:47
Copy link
Collaborator

@zachschuermann zachschuermann left a comment

Choose a reason for hiding this comment

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

ah very awesome! and maybe worth having a quick line in the readme that says when you do --all-features we default to the oldest arrow supported?

Comment on lines +18 to +19
echo "testing with --features ${ARROW_VERSION}"
cargo run --features ${ARROW_VERSION}
Copy link
Collaborator

Choose a reason for hiding this comment

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

This seems a bit counterproductive, given that arrow is only useful if default-engine or sync-engine feature is specified (unless they're default features, which I doubt)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

we always depend on kernel with default-engine and sync-engine (see integration-tests/Cargo.toml). This flag on this crate just adds the dependency on kernel with the particular specified arrow_x flag.

Comment on lines 4 to 10
#[cfg(all(feature = "arrow_53", feature = "arrow_54"))]
compile_error!("Multiple versions of the arrow cannot be used at the same time!");
pub use arrow_53::*;

#[cfg(feature = "arrow_53")]
#[cfg(all(feature = "arrow_53", not(feature = "arrow_54")))]
pub use arrow_53::*;

#[cfg(feature = "arrow_54")]
#[cfg(all(feature = "arrow_54", not(feature = "arrow_53")))]
Copy link
Collaborator

Choose a reason for hiding this comment

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

The current combo works but I suspect it would get out of hand quickly if we ever need to support 3+ arrow versions? Also not super easy to read. What if we did:

#[cfg(feature = "arrow_53")]
pub use arrow_53::*;

#[cfg(all(feature = "arrow_54", not(feature = "arrow_53")))]
pub use arrow_54::*;

#[cfg(all(feature = "arrow_55", not(feature = "arrow_54"), not(feature = "arrow_53")))]
pub use arrow_55::*;

etc

Should be easier to tell what's going on, and it's "only" a quadratic number of terms instead of a combinatoric explosion. When it's time to drop support for the oldest version, we just delete the top entry and remove it from the end of each remaining list.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yep, this is much nicer. Updated, thanks!

@nicklan nicklan requested a review from scovich February 21, 2025 18:21
@nicklan
Copy link
Collaborator Author

nicklan commented Feb 21, 2025

ah very awesome! and maybe worth having a quick line in the readme that says when you do --all-features we default to the oldest arrow supported?

Good call. The README was actually totally wrong, so I've fixed it now :)

@zachschuermann
Copy link
Collaborator

for some reason it looks like the semver checks are still failing with the "multiple versions of arrow specified"? not sure if we just need to rerun? Shouldn't this PR fix that?

@nicklan
Copy link
Collaborator Author

nicklan commented Feb 21, 2025

for some reason it looks like the semver checks are still failing with the "multiple versions of arrow specified"? not sure if we just need to rerun? Shouldn't this PR fix that?

It tries to build main which is the part that fails. It should fix things once this merges.

@zachschuermann
Copy link
Collaborator

thanks sorry forgot it's also building base rev :)

Comment on lines 4 to 5
#[cfg(feature = "arrow_53")]
pub use parquet_53::*;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Shouldn't we also select arrow/parquet 53 if no version was specifically requested? Otherwise people have to specify something just to compile, even if they don't care what arrow version they use.

Copy link
Collaborator

@zachschuermann zachschuermann left a comment

Choose a reason for hiding this comment

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

restamping :) LGTM!

@nicklan nicklan requested a review from scovich February 22, 2025 00:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change Change that will require a version bump
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants