This is a bit confusing. It is very normal to provide PEM file contents as a string in languages. We should differentiate file path better. Maybe Union[pathlib.Path, str, bytes] and only paths are treated as such?

I've changed the typing to your suggestion but I'm unsure whether or not to keep the str type.

The core TOML parser reads the cert configs into:

pub enum DataSource {
    Path(String),
    Data(Vec<u8>),
}

so lang only sees these cert configs as bytes or a path (which we now read as an actual Path type).

Users can provide file contents as string but it would only be possible programmatically, like the (added) test test_read_source_from_string_content (unless I'm misunderstanding something). I am not sure if we wanted envconfig to be used this way

The core TOML parser reads the cert configs into:

Rust has a clearer difference between paths and data. It is normal in Python to have a string of data. test_read_source_from_string_content is actually test_read_source_from_bytes_content because you have a b in front. I think it makes sense to accept string content too since PEM data is often a string, but if not, no prob, let's just make sure the exception is clear if the data type is wrong.

test_read_source_from_string_content reads in string content, but asserts that it is read correctly into bytes.
So it's still from string content so to speak.

We should not silently drop/ignore invalid data types in this case at runtime, should raise here IMO

raise a TypeError if invalid

I think it may make more sense to have a temporalio/bridge/envconfig.py module that wraps all the bridge stuff. Every other use of the bridge in this repo goes through that approach. But not required.

If we want this here, can this be moved to the bottom of the kwarg list and be called override_env_vars to be clear that it's abnormal to set?

moved/renamed

Can you have somewhere that splats this on to .connect and makes an actual connection (say to the same dev server used in other tests or start your own if you must)? We need something to confirm type checking on the result of the load_client_connect_config call that it matches the connect arg expectations.

added

I wonder if we can combine all of these load calls into one to reduce surface area since they are not the commonly called methods. I know Go doesn't combine them because it's a bit harder for that language. I figure you have one load call that can accept config file override (can be path or data like cert), disable env, override env, etc.

As for the load_profile stuff, wouldn't that just be load on ClientConfigProfile instead of this class? Most of the same parameters should apply.

done, some changes to the bridge to support this

We want users to be able to convert this (and ClientConfigProfile) to/from TOML on their own if they want. However, we don't necessarily need to expose literal TOML conversion, just the ability to convert to/from the dict that represents TOML (they can use some Python TOML library if they want to do the TOML part). Can we expose to_dict and from_dict on this and the ClientConfigProfile class that represents exactly what it looks like in TOML?

added to_dict methods
the resulting dictionaries are well-typed, not sure if that was necessary or not

one caveat with this, when the given config input is in bytes
to_dict converts bytes data into strings because strings are more suitable for TOML

I wrote it in a test for this, converting from to_dict -> from_dict -> compare:

    # We expect the new profile to be the same, but with bytes-based data
    # sources converted to strings. This is because to_dict converts
    # bytes-based data to a string, suitable for TOML. So we only have
    # a string representation to work with.

I was originally going to say you could leave these out since users using to/from dict should not really care about the types since that's low level. But I now see that we also are dogfooding the dict serialization stuff (awesome), so can leave even if just for our benefit.

Just a heads up here, I think we may be having another situation ("plugins") where this actually has value at the client level for others wanting to type a dict for the kwargs of connect/init. So this may move to the client module in the future.