-
Notifications
You must be signed in to change notification settings - Fork 671
feat(downloads): allow streaming downloads access to response iterator #1956
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1956 +/- ##
=======================================
Coverage 94.72% 94.73%
=======================================
Files 78 78
Lines 5083 5087 +4
=======================================
+ Hits 4815 4819 +4
Misses 268 268
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Thank you for all the work here @TCatshoek! For this to work with typing on 3.7, we'll need to add a conditional dependency on https://pypi.org/project/typing-extensions/. It would also be great to document this a little and if you could maybe add a specific use case there (e.g. from your issue) a bit to give context :) I think doing this with As a bonus, if you have the energy, it'd be great if we could maybe also do a functional test for this. I know we don't have any targeted tests for this but perhaps down here: python-gitlab/tests/functional/api/test_packages.py Lines 38 to 62 in 5a1678f
|
Allow access to the underlying response iterator when downloading in streaming mode by specifying action="iterator" Update type annotations to support this change
This supports commit c76b3b1 and makes sure it works on python 3.7 as well.
This is used to support Literal from typing on python < 3.8
I added the conditional dependency on typing_extensions for python 3.7. Had to shuffle some imports around to make the linter happy, I hope it is ok like this! |
Document the usage of the action="iterator" option when downloading artifacts
Tests for the functionality implemented in 4f9807f
Added tests and documentation too! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few suggestions for the docs @TCatshoek and I'll just check if it makes more sense to add another argument, I'll get back to you ASAP. Thanks :)
requirements.txt
Outdated
@@ -1,2 +1,3 @@ | |||
requests==2.27.1 | |||
requests-toolbelt==0.9.1 | |||
typing_extensions; python_version<"3.8" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works in testing, but I assume we'd also need this in setup.py
for the installed package for users.
However, let me just take another look because if we're only doing this for Literal
, it might make more sense to add a separate argument in addition to action
, to keep typing clearer. (Also we'd need to change the docstrings otherwise)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes, you're right. Let me know what you decide and I will update things accordingly!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nejch Any news on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your patience @TCatshoek!
I just took another look at this and I feel we should maybe leave action
a Callable only because we do this later:
Lines 44 to 46 in 792cee9
for chunk in response.iter_content(chunk_size=chunk_size): | |
if chunk: | |
action(chunk) |
So I think that might be a bit confusing. How about an explicit iterator: bool = False
argument that would follow the streamed
logic a bit more? This would also get rid of the typing dependency we discussed as I see some people don't like having even the tiniest extra dependencies.. :)
Thanks again for working on this! Let me know what you think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just had some discussion with @JohnVillalovos and we're thinking of intruducing an iterator=True
for our list()
calls where we currently use as_list=False
(which is kind of unclear in what it really does currently), so this would then make it a consistent interfaces as well. So I think a bool with iterator
is the way to go,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good! I'll get to it asap, work has been keeping me busy :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool! No rush. FYI, the list iterator argument has been merged:
#2032
Co-authored-by: Nejc Habjan <hab.nejc@gmail.com>
Sorry, had to force push because the commit messages from accepting the suggested changes through the web interface were not accepted. |
Would you still be interested in adapting this for |
Yeah! I think I should have some time this weekend, I'll try to get it done before the 28th |
This reverts commit 8cc4cfc.
…thon 3.7" This reverts commit efd8b48.
… iterator" This reverts commit 4f9807f.
…r downloads Instead of having action="iterator", we can now do iterator=True to get the underlying response iterator when downloading things.
Adapted the existing tests for the new iterator=True argument
Adapted the example for the new iterator=True argument
Thanks for all the work here @TCatshoek! |
@nejch Glad I could help! :D |
Allow access to the underlying response iterator when downloading in
streaming mode by specifying action="iterator"
Also update type annotations to support this change