:thumbsup:

In the current code, the lib relies on the calling function to handle such expansions. It makes sense to consolidate, since we seem to always want this.

I wonder if it is better to do it here, or would it be better to do it in ClientSession where the values are used?

@mikem My idead was to expand it ASAP, so we deal with sanitized paths later. But yes, we can do that later - but wouldn't it be more confusing?

My idea was to expand it ASAP, so we deal with sanitized paths later. But yes, we can do that later - but wouldn't it be more confusing?

I'm not sure myself, but I thought it was worth considering before we pick a solution.

Can we imagine a situation where we'd want the literal value of the config, rather than the expansion?

Do we anticipate any situations where ClientSession receives such values from somewhere other than the config data and is expected to expand them?

For first question, I don't think so. For the second one - yes, it is possible, but in that case it should be user's responsibility to pass valid (expanded) values.

Commit 96a964dd fixes this pull-request