context: we use the azure SDK as a dependency but we would like to avoid usage of async-io anywhere in our dependency chain and continue using tokio only.

@heaths for the record, this issue still exists on the main branch, so maybe remove the label?

azure_identity is not required by azure_core nor will it ever be - not for dependencies, at least; but, perhaps, for dev-dependencies for examples and such. azure_core itself does not depend on reqwest solely - only by default for an HTTP stack, but we fully support using a different HTTP and/or async runtime stack e.g., monoio which we'll add to our test matrix at some point. Thus, I don't want an explicit dependency on any async runtime for unconditional production code.

For the legacy branch this was primarily left in place as a tracking issue and would eventually be closed if no one else commented on it. But, as the "issue" still exists in the main branch, could you elaborate on what the "issue" actually is? Just that you don't want async-io anywhere in the call stack? Do you actually use azure_identity? I could imagine us using https://docs.rs/tokio/latest/tokio/process/index.html by default but, like with our HTTP stack, we'd have to abstract this away. In that case, I could see relabeling this or opening a dup just for the main branch.

@RickWinter, thoughts? We'd need to prioritize this. At a glance I suspect a couple of days to build and test an abstraction that could work for a couple of async process runtimes out there like the async-process we use now and tokio::process.

Do you actually use azure_identity?

For us, one of the reasons for using the SDK instead of manual HTTP calls is that we can use the SDK provided auth methods instead of having to code them ourselves. So we do indeed use azure_identity. We use multiple auth methods: some in staging/prod that is hosted on Azure, some in CI which is not hosted on Azure but needs to connect to Azure containers as part of the testsuite, and some for local development.

Just that you don't want async-io anywhere in the call stack?

Yeah, it's general advice to avoid using multiple different async runtimes, and we'd like to follow that. An abstraction like it exists for the http client would be amazing (and it's pretty nice that it exists for the http client, that way for example we can enable http pooling locally).

@RickWinter @ronniegeraghty I'd like to convert our process implementation we use in azure_identity to tokio::process by default but, no later than beta 2, abstract that away to support other async runtimes. We already depend on tokio by default for our HTTP et. al. stacks so it makes sense not to run two different async runtimes by default in practical cases i.e., using some other Azure SDK + azure_identity.

Filed a successor to #1654: #2175