add arun_deployment

[zzstoatzz]

removes sync_compatible from run_deployment

[codspeed-hq]

CodSpeed Performance Report

Merging #16605 will not alter performance

_{Comparing run-deployment-async (010e4cb) with main (8b8eea2)}

Summary

✅ 3 untouched benchmarks

[zzstoatzz]

this is because the sync and async versions of run_deployment need to take different types of clients. i could make them both Optional[Any] but thought that would be more unclear and this way it pushes folks who care about typing to use the explicit async one

[desertaxle]

While this is decorated with @async_dispatch, I think we might need to only accept PrefectClient instances. My thinking is that if a SyncPrefectClient is passed in an async context, then arun_deployment will fail.

The transition will be a little messy, but I think we can create a sync client internally if one isn't passed and handle a provided async client with run_coro_as_sync. Once we start warning on async dispatch, we can also start warning on passed async clients so that users know to provide a sync client or use arun_deployment.

[zzstoatzz]

ah that's a great point

[zzstoatzz]

hmm the tricky thing about this is that run_coro_as_sync might try to put it in a new thread, which causes "bound to a different even loop" issues 🤔

[zzstoatzz]

in the case where an async client is passed to run deployment in a sync context, im not sure how to call those asynchronous methods without running into the bound to a different event loop

... i could just create a new client (which works) but not using the client that was explicitly passed feels wrong