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

Make rustls default across all packages #1097

Merged
merged 14 commits into from
Feb 11, 2023

Conversation

wjones127
Copy link
Collaborator

Description

Clean up our tls options so that we can run cargo test at the top level again.

Also fixed clippy warnings that had accumulated.

Related Issue(s)

Documentation

delta-inspect/Cargo.toml Outdated Show resolved Hide resolved
@houqp
Copy link
Member

houqp commented Jan 25, 2023

Thank you @wjones127 for taking a stab at this!

@github-actions github-actions bot added the binding/rust Issues for the Rust crate label Jan 25, 2023
@wjones127 wjones127 changed the title Refactor rustls features so workspace can be checked. Make rustls default across all packages Jan 25, 2023
@@ -333,8 +333,12 @@ mod tests {
#[tokio::test]
async fn test_create_local_relative_path() {
let table_schema = get_delta_schema();
let name = Alphanumeric.sample_string(&mut rand::thread_rng(), 16);
let table = DeltaOps::try_from_uri(format!("./{}", name))
let tmp_dir = TempDir::new_in(".", "tmp_").unwrap();
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

These tests were creating directories without cleaning them up.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Thanks for cleaning that up!

@@ -4,7 +4,7 @@
//!
//! # Example
//!
//! ```
//! ```no_run
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Can't run this on MacOS, and wasn't sure how to opt out of doc test based on platform.

@wjones127
Copy link
Collaborator Author

Well I've figured out most of the issues, but the Windows build I haven't figured out 😢

@houqp
Copy link
Member

houqp commented Feb 7, 2023

@wjones127 have you tried kicking off the windows build without loading the previous build cache?

@wjones127
Copy link
Collaborator Author

@houqp Thanks, clearing the cache worked!

@@ -230,16 +216,10 @@ impl ObjectStoreKind {
}),
#[cfg(feature = "gcs")]
ObjectStoreKind::Google => {
let store = GoogleCloudStorageBuilder::new()
let store = GoogleCloudStorageBuilder::from_env()
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The integration tests were failing for GCP without this change. In the tests, we configure GCP through the GOOGLE_SERVICE_ACCOUNT environment variable, but instead this code was creating a GCS storage with default configuration.

Is there a reason we shouldn't be picking up the environment variables first? I assume that the storage options override them. @roeap

Copy link
Collaborator

Choose a reason for hiding this comment

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

That must have been a bug, or at least an inconsistency. I think for S3 and Azure we use from_env as well. That said., this is actually a point I struggled with a bit when writing this. Mainly for S3 and Azure where we have many different ways of authorising. One scenario in particular was troubling me. In case the environment contains enough information for the store to find a credential, and the storage options contain another complete set of config for a credential. In this case object_store will pick the credential based on the order they are checked in the builder, which does not necessarily give precedence to the one in the options, which I assume is what the user would want.

The initial approach was to try and create one only from the storage_options, and if we fail, load from environment and from options. TO be honest, I do not remember what the specific issue was why I abandoned this approach, but I do remember, that the special handling of allow_http is definitely related. In the end I guess, I though in scenarios where tables in multiple locations are managed people should be careful what to put in the env...

That said, anything in storage options will overwrite any info parsed from the environment.

Copy link
Collaborator

@roeap roeap left a comment

Choose a reason for hiding this comment

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

Great work - will be nice running cargo from the root again 😆 .

@@ -333,8 +333,12 @@ mod tests {
#[tokio::test]
async fn test_create_local_relative_path() {
let table_schema = get_delta_schema();
let name = Alphanumeric.sample_string(&mut rand::thread_rng(), 16);
let table = DeltaOps::try_from_uri(format!("./{}", name))
let tmp_dir = TempDir::new_in(".", "tmp_").unwrap();
Copy link
Collaborator

Choose a reason for hiding this comment

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

Thanks for cleaning that up!

@wjones127 wjones127 merged commit 3ecf0e9 into delta-io:main Feb 11, 2023
@wjones127 wjones127 deleted the fix/cargo-check-working branch February 11, 2023 22:01
chitralverma pushed a commit to chitralverma/delta-rs that referenced this pull request Mar 17, 2023
# Description

Clean up our tls options so that we can run `cargo test` at the top
level again.

Also fixed clippy warnings that had accumulated.

# Related Issue(s)

- closes delta-io#985


# Documentation

<!---
Share links to useful documentation
--->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
binding/python Issues for the Python package binding/rust Issues for the Rust crate delta-checkpoint delta-inspect rust storage/aws AWS S3 storage related
Projects
None yet
Development

Successfully merging this pull request may close these issues.

cargo test does not run due to tls conflict
3 participants