stravalib
stravalib copied to clipboard
hozn
Deprecated endpoints in the STrava API
This is related to #212 . There are several endpoints in the API that have been deprecated. Given this, we should remove those methods from the package to avoid user confusion.
Get_running_Races and get_running_race are two that i just discovered via my docs update. (see pr #229 ). There probably are others as well so we should revisit. a test suite on CI would help us identify these issues in the future. but for now we can begin to remove methods that hit deprecated end points.
As part of #241 (which fixes another unrelated problem), I removed the running_race(s) endpoints to prevent CI from failing.
ok cool... so @jsamoocha i'm not sure if @hozn is still around - i know they were super busy. One of my big concerns here with this awesome package is that we can't run the test suite on CI. and as such when changes are made, it's hard to see if they break other things without setting up locally ... curious what you think about that? i'm just helping where i can here but i wondered if it's worth trying to find someone who would be willing to come in and revamp the test suite so it runs on CI.
would make merging SO MUCH EASIER!!
@jsamoocha i would like to to close this issue as I think you've been deprecating end points and calling warnings when need be for unsupported but existing endpoints. Did you see #232 ? i haven't tested any of this because i've been focused on updating docs but can once i'm done with the big docs revamp that i'm working on. that likely won't be until next week.
i could close this issue and we could just tag 232 as an end point priority too if it hasn't been addressed already. let me know what you think. i'm trying to close / address / tag issues since we have so many.
About endpoint/parameter deprecations: whenever I'm writing tests I try to manually call the API with a test account to check what is supported.
For endpoints that Strava has already removed, I'm in favor of removing them as well from stravalib. For users, it doesn't seem to matter if they're faced with a breaking NotImplementedError or a breaking AttributeError (because we removed the method from client).
For endpoints that are newly added by Strava, let's make specific issues for them (see #282 e.g.).
The tagging you suggested is a good idea: I just made two new labels for that (endpoint change [(BREAKING)])
I'll now close this issue as you suggested.