-
Notifications
You must be signed in to change notification settings - Fork 10
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
Migrate from requests
➡️ httpx
#312
Conversation
Also shuffle some functions around and simplify things.
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## dev_master #312 +/- ##
==============================================
+ Coverage 80.32% 80.77% +0.45%
==============================================
Files 148 148
Lines 14902 14867 -35
==============================================
+ Hits 11970 12009 +39
+ Misses 2932 2858 -74 ☔ View full report in Codecov by Sentry. |
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.
I didn't know about httpx, seems like the successor to requests that everyone agrees upon.
Sad to see requests go, it was such a relief when requests was released and it feels like it started a wave of great Python libraries. I like the "Readme Driven Development" model. But no async support is pretty bad. Time to move on.
I noticed you removed all the retry functionality. Are we sure this is not necessary anymore? Let's assume it is indeed fine, and we can add it back later if necessary.
Let's see how this goes!
Retry is still done: https://github.com/AstarVienna/ScopeSim/pull/312/files#diff-6a1f75ec7a32e1ba7c5cb73ec6c29b040624cc828fff8361be76c0113d1dbae1R42 It works a bit differently than in requests, and seems somewhat less configurable (or maybe it isn't, but the documentation is somewhat lacking in that regard). But than again, I don't think we really actually needed all that configurability anyway... |
The
httpx
package seems to handle web requests better and is easier to work with than the previouslyrequests
package. So let's use this instead, as already done in another of our packages.API changes
server.database.ServerError
➡️server.download_utils.ServerError
.server.database.get_server_folder_contents()
➡️server.download_utils.get_server_folder_contents()
and addclient
argument.client
argument toserver.database.crawl_server_dirs()
.client
argument toserver.database.get_all_package_versions()
.client
argument toserver.database.get_package_folders()
.client
argument toserver.database.get_server_folder_package_names()
.client
argument toserver.database._download_single_package()
.server.database.get_all_packages_on_server()
to simply wrapserver.database.crawl_server_dirs()
.from_cache
argument fromserver.database.download_packages()
.server.download_utils.handle_download()
and addserver.download_utils.send_get()
to better fit the new backend.On the
client
As stated in the documentation, using a
httpx.Client
(similar in concept and function torequests.Session
) has several performance benefits. Actually keeping the (context-managed) client instance around during one task will ensure we can actually make proper use of this. Best example:download_packages
makes two separate requests to the server, first to get the version and location information for the requested packages and second to perform the actual download. This used to be done with separate sessions (or none at all), while it is now done using a single client. This already has a notable performance boost, especially for slower networks. Any function that could benefit from this now has a (usually optional)client
argument, as mentioned above. In the cases where it is optional (mostly functions that could be called from outside as well, e.g. to just list versions of packages on the server), if no client is given, a new one will be created for the scope of the function. This ensures that we can get both: optimal performance when the function is called from somewhere that already has a client, and easy standalone use without having to manually create a client first.Other changes
Further considerations
Tip
Unlike
requests
, thehttpx
package is built from the ground up to support async functionality. While not currently used, it should be relatively straightforward (as much as any async stuff in Python ever is) to do that.Note
A number of our current users are experiencing troubles with the download from the IRDB server (while the GitHub-based download does not appear to have the same issues). I would be interested to see if these changes solve that.
Note
As this includes substantial enough changes to the public API (most notably the change to
server.database.download_packages()
), this should mandate a new minor version (v0.8.0) in my opinion.