Supply chain risk reduction: remove dependency on library named deprecated

[akx]

No need for an external library just for 5 annotations.

Pull Request check-list

Please make sure to review and check all of these items:

• Does $ tox pass with this change (including linting)?
• Do the CI tests pass with this change (enable it first in your forked repo and wait for the github action build to finish)?
• Is the new or changed code fully tested?
• Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?
• Is there an example added to the examples folder (if applicable)?
• Was the change added to CHANGES file?

Description of change

This PR removes the dependency on the @deprecated library in favor of a simple 8-line function.

[chayim]

While this removes the dependency, I don't really see this as necessary. It's less expressive than a decorator - and I'd like to keep that interface. If you'd like to introduce a decorator that provides the same namespace, that's a separate conversation.

As a project, it would appear that deprecated has stalled. But, the need to decorate functions, potentially classes, and definitely arguments exists.

[akx]

@chayim Thanks for the comments.

My reasoning is that pulling in two dependencies (deprecated and its dependency wrapt) just to basically format a string and call warnings.warn() in 5 places is unwarranted. I also feel there's a nonzero supply chain risk in it for such a heavily used project such as redis-py. (One could also argue that it's more cost-effective bandwidth-wise, and better for the environment to not have the world necessarily download those extra dependencies some million times per day...)

As for the expressiveness, if you're thinking about e.g. introspecting functions to see whether they're @deprecated, I don't think that really matters..?

For instance, Django happily just calls warnings.warn without a wrapper wherever they need to warn about a deprecation, á la https://github.com/django/django/blob/10bb21e71e3668f770493e2af0d0e0271830f7a3/django/db/models/expressions.py#L1551-L1561 ...

[codecov-commenter]

Codecov Report

Base: 92.17% // Head: 92.17% // No change to project coverage 👍

Coverage data is based on head (9fe8366) compared to base (9fe8366).
Patch has no changes to coverable lines.

❗ Current head 9fe8366 differs from pull request most recent head b9d88e0. Consider uploading reports for the commit b9d88e0 to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2386   +/-   ##
=======================================
  Coverage   92.17%   92.17%           
=======================================
  Files         110      110           
  Lines       28924    28924           
=======================================
  Hits        26661    26661           
  Misses       2263     2263           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[akx]

@chayim Have you had a chance to look at my comments above?

[chayim]

@akx I'm more than happy to reduce any (and frankly all) dependencies. I'd like to hard reduce them in general, and keep things tidy. However, I'd like to maintain deprecation as a decorated interface, rather than an in-function call.

The differences may be minor, but I believe it improves readability, which is something we generally need to improve.

I'm VERY pro removing the dependency. However, that merge would be contingent on a decorator providing the same functionality. Any chance you're interested in modifying your PR accordingly (pretty please!)?

[akx]

@chayim Sure, I added a deprecated_function decorator that does what deprecated did for functions. When single parameters may be deprecated in the future, the function would call warn_deprecated directly.

[chayim]

@dvora-h when you're cool with this... let's get it into the next milestone (this week!)?. Unfortunately @akx I can't review this due to timing. But, love that we're going down this path...

[dvora-h]

@akx LGTM!
Can you just add your decorator to the deprecated commands in SEARCH so the CI will pass? I added deprecation to them after you opened this PR...

[akx]

@dvora-h Sure! Rebased & fixed search.