Skip to content

Base environment configuration module#931

Merged
THardy98 merged 5 commits intomasterfrom
env_config
Jun 9, 2025
Merged

Base environment configuration module#931
THardy98 merged 5 commits intomasterfrom
env_config

Conversation

@THardy98
Copy link
Copy Markdown
Contributor

@THardy98 THardy98 commented Jun 6, 2025

What was changed

Added envconfig.rs, a Rust port of the Go envconfig module. This is intended to be used by lang-SDKs, which will effectively have a wrapper on top of this, along with some additional functionality for environment configs to interoperate with SDK-specific client options.

Why?

Customer demand, useful utility

  1. Part of the work for [Feature Request] Environment configuration features#441

  2. How was this tested:
    Ported over the relevant tests from the Go module, along with a couple additional tests.

  3. Any docs updates needed?
    No ?

@THardy98 THardy98 requested a review from a team as a code owner June 6, 2025 11:50
Copy link
Copy Markdown
Contributor

@cretz cretz left a comment

Choose a reason for hiding this comment

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

This looks great, nothing blocking. Wanting to peek at Python draft at least before approving to confirm we have everything we need here, but I believe we do.

Comment thread core-api/src/envconfig.rs

/// ClientConfig represents a client config file.
#[derive(Debug, Clone, PartialEq, Default)]
pub struct ClientConfig {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I wonder for pure Rust users if we want to support a builder on this too, but I'm fine without it

Copy link
Copy Markdown
Member

@Sushisource Sushisource left a comment

Choose a reason for hiding this comment

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

Looking pretty good, can tighten up some types.

Comment thread core-api/src/envconfig.rs
Comment thread core-api/src/envconfig.rs Outdated

/// Options for loading a client configuration profile
#[derive(Debug, Default)]
pub struct LoadClientConfigProfileOptions<'a> {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Imo for both this and the one before, don't include env_lookup by ref here inside the struct, I would just pass it separately into the function that accepts these

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

And since we are using this in lang that we probably won't have callbacks before, I'd be ok just accepting a hash map of string-string here to override env instead of a trait.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I've opted for a hash map of string-string. In either case lang has to implement something to get env vars, I think passing the result of that implementation (i.e. the hash map) is simpler bridge code than passing the trait implementation itself.

Comment thread core-api/src/envconfig.rs Outdated
Comment thread core-api/src/envconfig.rs Outdated
Comment on lines +116 to +120
/// Path to client mTLS certificate. Mutually exclusive with ClientCertData.
pub client_cert_path: Option<String>,

/// PEM bytes for client mTLS certificate. Mutually exclusive with ClientCertPath.
pub client_cert_data: Option<Vec<u8>>,
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This should just be a little enum that allows you to pick one of the other, and is non-optional. Embrace types that make bad states unrepresentable.

Copy link
Copy Markdown
Contributor Author

@THardy98 THardy98 Jun 9, 2025

Choose a reason for hiding this comment

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

done

In place, I've added validation that a user cannot specify both path and data in their TOML + env vars, apply_data_source_env_var.

You can overwrite a TOML field with the same env var (i.e. env var path -> TOML path), but supplying some combination of:

  • TOML path & TOML data
  • TOML path & env data (or vice versa)
  • env path & env data

is an invalid configuration.

Same logic applies to other mutually exclusive fields.

Comment thread core-api/src/envconfig.rs Outdated
Comment thread core-api/src/envconfig.rs Outdated
Comment thread core-api/src/envconfig.rs Outdated
Comment thread core-api/src/envconfig.rs Outdated
Comment thread core-api/src/envconfig.rs Outdated
THardy98 added 2 commits June 9, 2025 18:04
…ding both, read env vars from hashmap instead of trait env lookup
@THardy98 THardy98 requested a review from Sushisource June 9, 2025 16:07
Copy link
Copy Markdown
Member

@Sushisource Sushisource left a comment

Choose a reason for hiding this comment

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

Looking good!

@THardy98 THardy98 merged commit e57fae8 into master Jun 9, 2025
29 of 31 checks passed
@THardy98 THardy98 deleted the env_config branch June 9, 2025 21:43
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.

3 participants