-
Notifications
You must be signed in to change notification settings - Fork 406
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
Conversation
Thank you @wjones127 for taking a stab at this! |
@@ -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(); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
46178df
to
693361a
Compare
Well I've figured out most of the issues, but the Windows build I haven't figured out 😢 |
@wjones127 have you tried kicking off the windows build without loading the previous build cache? |
@houqp Thanks, clearing the cache worked! |
6b566ce
to
b6bd80b
Compare
@@ -230,16 +216,10 @@ impl ObjectStoreKind { | |||
}), | |||
#[cfg(feature = "gcs")] | |||
ObjectStoreKind::Google => { | |||
let store = GoogleCloudStorageBuilder::new() | |||
let store = GoogleCloudStorageBuilder::from_env() |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
b6bd80b
to
b99e3be
Compare
There was a problem hiding this 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(); |
There was a problem hiding this comment.
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!
# 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 --->
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)
cargo test
does not run due to tls conflict #985Documentation