Is your feature request related to a problem? Please describe.
Not applicable
Describe the solution you'd like
I would like the ability to install some version of azure-identity and azure-cosmos to a pyodide environment with the end goal of being able to obtain a credential and query a cosmos database using said credential from a python script running on pyodide in browser.
It would be excellent if the azure-identity DefaultAzureCredential function was able to handle the credential retrieving (perhaps by checking for a session cookie?), allowing the same script to be run in a local python install or in a pyodide browser environment.
Describe alternatives you've considered
It seems that an intern of yours did some work on this about a year ago as evidenced by this blogpost and some PRs from the time. The blogpost method, however, seems to rely on statically providing the credential, not programmatically retrieving one. Moreover, the azure-cosmos package, I believe, relies on aiohttp and requests which are incompatible with pyodide(?).
Additional context
My colleagues and I (an MLOps team) frequently are asked to run ad hoc reports by others at our institution. These reports typically involve some combination of pulling data from cosmos, analyzing/transforming the data, and generating informative plots and/or csv files. We would like to empower the recipients of these reports to be able to rerun them themselves and/or tweak the parameters of the query or analysis. We could share the python scripts/notebooks; the main sticking point, however, seems to be the overhead of creating and maintaining a python environment to run said notebooks. This leads me to pursuing the possibility of sharing the reports in an editable and browser-runnable format a la Jupyterlite or something similar. If we were to do something like this, it would be important that the credentials are not shared with the script and, in fact, were linked to each user of the script, ensuring that no one is able to access data they should not be able to.
Just wondering if this is still in the cards or not, and, if so, what the approximate timeline would be. Thank you!
Is your feature request related to a problem? Please describe.
Not applicable
Describe the solution you'd like
I would like the ability to install some version of azure-identity and azure-cosmos to a pyodide environment with the end goal of being able to obtain a credential and query a cosmos database using said credential from a python script running on pyodide in browser.
It would be excellent if the azure-identity DefaultAzureCredential function was able to handle the credential retrieving (perhaps by checking for a session cookie?), allowing the same script to be run in a local python install or in a pyodide browser environment.
Describe alternatives you've considered
It seems that an intern of yours did some work on this about a year ago as evidenced by this blogpost and some PRs from the time. The blogpost method, however, seems to rely on statically providing the credential, not programmatically retrieving one. Moreover, the azure-cosmos package, I believe, relies on aiohttp and requests which are incompatible with pyodide(?).
Additional context
My colleagues and I (an MLOps team) frequently are asked to run ad hoc reports by others at our institution. These reports typically involve some combination of pulling data from cosmos, analyzing/transforming the data, and generating informative plots and/or csv files. We would like to empower the recipients of these reports to be able to rerun them themselves and/or tweak the parameters of the query or analysis. We could share the python scripts/notebooks; the main sticking point, however, seems to be the overhead of creating and maintaining a python environment to run said notebooks. This leads me to pursuing the possibility of sharing the reports in an editable and browser-runnable format a la Jupyterlite or something similar. If we were to do something like this, it would be important that the credentials are not shared with the script and, in fact, were linked to each user of the script, ensuring that no one is able to access data they should not be able to.
Just wondering if this is still in the cards or not, and, if so, what the approximate timeline would be. Thank you!