Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This allows us to better understand the traffic we see to our server API. It is not identifiable to a person.
Motivated after seeing large spikes in traffic recently. Some of them coming from
requests/1.x.x
agents - which leaves us wondering if this is from Python API users (potentially indirectly through e.g., the automlbenchmark), or scripts/bots that don't identify themselves as such.On top of this PR, I think we might want to make our user-agent configurable so that services building on top of
openml-python
can identify themselves (e.g., automl benchmark, experiment bots). But I don't want to get into that right now.I updated the unit tests that would otherwise crash. I explicitly did not add a check for the agent with these tests.
To me it feels that would be outside the scope of those tests. In general, it's a thin line the way its set up - should our tests even fail if they would just keyword argument instead of a positional one? But that too felt out of scope, so I change it to a (in my opinion) slightly better version of the same tests.
I do not feel this warrants its own unit test. If I should make one, could you recommend an approach? Just mocking the requests library and then calling
_api_call
for all types of requests? I just thought that wasn't particularly useful.