feat: adds boilerplate for config with factories.

[tdstein]

Adds support for setting api_key and endpoint. Each value may be set by the caller or via environment variables. Values supplied by the user take precedence over variables set by environment variables.

The following environment variables are supported:

• CONNECT_API_KEY_KEY
• CONNECT_SERVER

Example Usage:

main.py

from posit.client import Client

client = Client(endpoint="http://localhost:8080")

CONNECT_API_KEY=foobar python main.py

[dbkegley]

Will sync vs async be a concern? I know httpx supports both but I don't know how important that might be for users of this client

[tdstein]

I'm not sure. I started with requests since it is the most popular HTTP library after urllib3. And the simplest to use, in my opinion.

Are there situations when calling the Connect API where asynchronous design becomes necessary?

[dbkegley]

pyshiny (and other fastapi-base apps) rely heavily on python's asyncio apis. This has come up in the databricks sql client as well. There are a few justifications for the request for async in this issue that might also be applicable for our client.

databricks/databricks-sql-python#176

[tdstein]

Thanks! httpx looks great, but it's marked as beta. Do you have opinions on aiohttp? That seems like the most stable library to bring in.

[dbkegley]

I haven't used it but that sounds like a good option to me. FWIW Joe also recommended aiohttp when we were asking him some questions about async shiny: https://positpbc.slack.com/archives/C03HH2ZUU/p1702668760303599

[nealrichardson]

I'm skeptical that we'll want to bother with async queries against the Connect API

[dbkegley]

If we expect the sdk to be used from inside Connect-hosted content like fastapi then a non-blocking api could be important. Based off of Joe's comment from the slack thread, it sounds like request's blocking IO is a problem for uvicorn apps.

uvicorn is single threaded, so requests.get(...) blocks any traffic from being served.

We should test this to confirm the behavior but if all other requests are blocked while we're waiting for a request to the Connect API to resolve then that could be a blocker for obtaining an access token inside a piece of content.

[tdstein]

Could someone write a uvicorn application that async wraps calls to this library?

I also wouldn't want to force a consumer to set up asyncio and into await'ing everything.

[dbkegley]

Could someone write a uvicornapplication that async wraps calls to this library?

Sure, probably. Let's table this for now. I think this is something that warrants more discussion though. We should test what it feels like to use this SDK from different content types in Connect. Especially single-threaded uvicorn content like pyshiny and fastapi. I'm interested to see whether the content can service multiple requests at the same time without using an async requests library

[nealrichardson]

I agree, let's defer, this feels like YAGNI in PR #1. If we find out that we are bottlenecking because of this, we should totally revisit.

[nealrichardson]

Should all of this go under src/posit/connect? I wouldn't presume that the other product APIs will auth the same way.

[tdstein]

Since this is starting to balloon, I will merge this and split discussions downstream.

[tdstein]

Should all of this go under src/posit/connect? I wouldn't presume that the other product APIs will auth the same way.

Yes, it should.