Repository: sopel-irc/sopel

Issue:
Deprecation warnings should be printed for dev versions
### Description

`sopel.logger.get_logger` is [marked](https://github.com/sopel-irc/sopel/blob/eac71b07d60d3bea68fe3f1242e88654594a7df5/sopel/logger.py#L164) as [deprecated](https://sopel.chat/docs/api.html#sopel.logger.get_logger), but no deprecation warning is raised when it's used.

### Reproduction steps

1. Create a Sopel plugin with `from sopel.logger import get_logger; LOGGER=get_logger(__name__)`
2. Start Sopel with that plugin
3. No deprecation warnings are produced

### Expected behavior

A deprecation warning is produced

### Relevant logs

```shell
Tested by replacing the logger in admin.py.

[2022-06-11 13:00:50,089] sopel.bot            INFO     - Plugin loaded: ping
[2022-06-11 13:00:50,090] sopel.plugins.rules  DEBUG    - Command registered: <Command admin.join []>
[2022-06-11 13:00:50,090] sopel.plugins.rules  DEBUG    - Command registered: <Command admin.tmpjoin []>
[2022-06-11 13:00:50,091] sopel.plugins.rules  DEBUG    - Command registered: <Command admin.part []>
[2022-06-11 13:00:50,091] sopel.plugins.rules  DEBUG    - Command registered: <Command admin.tmppart []>
[2022-06-11 13:00:50,092] sopel.plugins.rules  DEBUG    - Command registered: <Command admin.chanlist [channels]>
[2022-06-11 13:00:50,092] sopel.plugins.rules  DEBUG    - Command registered: <Command admin.restart []>
[2022-06-11 13:00:50,093] sopel.plugins.rules  DEBUG    - Command registered: <Command admin.quit []>
[2022-06-11 13:00:50,093] sopel.plugins.rules  DEBUG    - Command registered: <Command admin.raw []>
[2022-06-11 13:00:50,094] sopel.plugins.rules  DEBUG    - Command registered: <Command admin.say [msg]>
[2022-06-11 13:00:50,094] sopel.plugins.rules  DEBUG    - Command registered: <Command admin.me []>
[2022-06-11 13:00:50,094] sopel.plugins.rules  DEBUG    - Rule registered: <Rule admin.invite_join (1)>
[2022-06-11 13:00:50,094] sopel.plugins.rules  DEBUG    - Rule registered: <Rule admin.hold_ground (1)>
[2022-06-11 13:00:50,095] sopel.plugins.rules  DEBUG    - Command registered: <Command admin.mode []>
[2022-06-11 13:00:50,095] sopel.plugins.rules  DEBUG    - Command registered: <Command admin.set []>
[2022-06-11 13:00:50,096] sopel.plugins.rules  DEBUG    - Command registered: <Command admin.unset []>
[2022-06-11 13:00:50,096] sopel.plugins.rules  DEBUG    - Command registered: <Command admin.save []>
[2022-06-11 13:00:50,096] sopel.bot            INFO     - Plugin loaded: admin
```


### Notes

_No response_

### Sopel version

eac71b07d60d3bea68fe3f1242e88654594a7df5

### Installation method

`pip install`

### Python version

3.10.4


Discussion:
My guess is that your Sopel's version is actually `8.0.0.dev0`: that's the version that is checked against `warning_in='8.0'`.

In that regard:

```
>>> parse_version('8.0') >= parse_version('8.0.0.dev0')
True
```
Therefore, this is not a bug, you are just not running Sopel 8.0 yet.
Ah. That... makes sense, but also leaves the opportunity for us to ship things that weren't marked deprecated until the version is set to true `8.0.0`.
A way to work around this that doesn't involve messing with that version comparison might be to unconditionally raise all deprecation warnings if running a dev version?
As soon as I saw this issue come up on IRC, I knew it would be down to how `parse_version` works with `dev` versions.

_Always_ unconditionally raising all deprecation warnings if running a `dev` version is… not my preferred solution. Whether done that way or by tweaking how the decorator compares versions (to ignore suffixes like `dev`), I don't want to change the code such that bumping to the next `dev` version can make a bunch of warnings suddenly appear. We need a window in which it's possible to check for deprecations without logs getting spammed.

I do _not_ have a strong preference on whether or not to add a tool in the code that makes the `warning_in` behavior stricter on request. From where I sit, it's good practice to go through all uses of `@deprecated` in the code every time we bump a minor or major version, removing or tweaking things that need it. We're also generally pretty good about updating usage when the decision to deprecate something first happens, so I'm not worried about this issue biting us in terms of core development. But I can also see the utility of, e.g., an "always warn for deprecations" flag on the command line.

@Exirel What do you think, new CLI option? I don't want to change the version comparison behavior, but forcing deprecation warnings could be a useful tool for plugin developers who want to stay ahead of the curve.
Fair, I patched that check locally and didn't see any warnings printed from core.

Alternatively, an environment variable like `SOPEL_PREVIEW_DEPRECATION=1` (or `=8.0`?)
> But I can also see the utility of, e.g., an "always warn for deprecations" flag on the command line.

That's a feature of the Python built-in `warning` module.
We were talking a while back about changing `@deprecated` to use `warnings.warn()` instead of the current `logger.warning()`. Do you remember why that idea got dropped? Maybe something about its interaction with `logging`, but I see there's [a stdlib integration for that](https://docs.python.org/3/library/logging.html#logging.captureWarnings).

Resolving patch:
diff --git a/sopel/lifecycle.py b/sopel/lifecycle.py
--- a/sopel/lifecycle.py
+++ b/sopel/lifecycle.py
@@ -141,8 +141,10 @@ def decorator(func):
 
     @functools.wraps(func)
     def deprecated_func(*args, **kwargs):
-        if not (warning_in and
-                parse_version(warning_in) >= parse_version(__version__)):
+        warn_ver = warning_in and parse_version(warning_in).release
+        this_ver = parse_version(__version__).release
+
+        if not (warn_ver and warn_ver >= this_ver):
             original_frame = inspect.stack()[-stack_frame]
             mod = inspect.getmodule(original_frame[0])
             module_name = None


Test patch: