generated client doesn't support proxies

[leifwalsh]

Is your feature request related to a problem? Please describe.

The generated client is nice - clean, ergonomic, and lean - but it doesn't provide the full ability to pass arguments through to httpx. In the case I care about right now, I need to pass a proxy configuration to it (and I need to do so in code, I cannot rely on environment variables for an uninteresting reason, which is that I need one application to use different proxies in different places).

Describe the solution you'd like

I believe something like #202 would help, but I'm open to other ideas. It occurs to me that the format of the proxies dict that httpx accepts is actually itself an implementation detail specific to httpx. requests, for example, uses keys like http and https while httpx's proxy keys are http:// and https://.

Describe alternatives you've considered

So far I've customized the client.py.jinja and endpoint_module.py.jinja templates in the obvious way, and it works, but I don't want to be subject to bugs if the templates change in future versions, I'd rather openapi-python-client intentionally support some form of proxy config.

[dbanty]

Hey @leifwalsh, thanks for opening this issue! Because of the long list of improvements that can be solved with #202, I've finally taking the time to put together an MVP for it. Would you check out #775 and see what you think? I even added a sample of proxies to the generated README—it's not the cleanest thing (you have to set base_url twice), but I'm trying to keep the basics as simple as possible. Any ideas you have to improve the design would be much appreciated!

[leifwalsh]

Yeah, I think that makes sense to me.

I think client.get_client() reads a little funny. How about get_http_client()?

[dbanty]

I think client.get_client() reads a little funny. How about get_http_client()?

Agreed!