feat: add stream_href method

[jkeifer]

Related issues and pull requests

• n/a

Description

I have a case where I am using read_href, but can significantly decrease memory usage if I use the chunks as they are downloaded rather than waiting for the the complete byte stream from read_href. Seeing that read_href is concatenating a stream, this change simply splits the chunked downloading from read_href into a new method stream_href, which read_href uses internally.

Checklist

• Add tests
• Add docs
• Update CHANGELOG

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (5683121) 79.73% compared to head (319325b) 79.79%.
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #123      +/-   ##
==========================================
+ Coverage   79.73%   79.79%   +0.06%     
==========================================
  Files          16       16              
  Lines         982      985       +3     
==========================================
+ Hits          783      786       +3     
  Misses        199      199              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jkeifer]

Actually, I may have jumped the gun on this one. If it isn't something that you want to support as part of the public API without a solid use-case then please leave this unmerged for a short while until I re-confirm the need.

[gadomski]

In addition to the name change, we should also add a stac_asset.blocking.open_href.

[jkeifer]

I'm not sure there's a particularly elegant way to make a blocking version of open_href. The fundamental problem is asyncio.run() will synchronously execute a coroutine, but open_href is different in that it is returning an AsyncIterable which itself needs to be, well, asynchronously iterated. As far as I understand it, you can't do async iteration without running in an event loop.

I did find a snippet on SO that shows how to do this: https://stackoverflow.com/a/55164899. I don't know how you feel about it, but I wouldn't want to maintain something like that in this lib--if a user really needs to use open_href in sync code I would say they can take on a solution like that.

[gadomski]

Nope, makes a lot of sense, thanks for pointing that out.