Adds a method `DebugPanel.init_app()` that gets called from
`DebugToolbar.init_app()`.
This allows DebugPanels to register their own routes, and do setup work
that should go across requests (as opposed to per-request setup) and
needs access to the Flask `app`-object.
Require Flask >= `2.2.0`.
I'm comfortable going up to requiring `3.x`, but when I grep'd for
places we use older Flask constructs, this was all I found.
So for now no need to jump further.
Flask `2.2.0` requires Python >= `3.7`, so also dropped older pythons.
The `packaging` lib is not listed in the `install_requires` list.
https://github.com/greyli/flask-extension-status/actions/runs/7129071225/job/19412328108
```
Run python -c "from flask import Flask; app = Flask(__name__); from flask_debugtoolbar import DebugToolbarExtension; DebugToolbarExtension(app)"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/opt/hostedtoolcache/Python/3.12.0/x64/lib/python3.12/site-packages/flask_debugtoolbar/__init__.py", line 6, in <module>
from packaging import version as version_builder
ModuleNotFoundError: No module named 'packaging'
Error: Process completed with exit code 1.
```
1. Update the test app
If I understand correctly, the debug toolbar will only be enabled if `app.debug` is `True`. So I added the `DEBUG=True` to the test app.
Related code: 2b8bf9cc44/src/flask_debugtoolbar/__init__.py (L114)
2. Update the `src/flask_debugtoolbar/__init__.py`
Fix the two if statements to prevent the following errors:
```
> if 'gzip' in response.headers.get('Content-Encoding'):
E TypeError: argument of type 'NoneType' is not iterable
```
Since the `response.headers.get('Content-Encoding')` could be None.
With this PR, all the tests will be passed. The failed style checker will be fixed in #219
* Remove the branch constraint for pull request triggering
* Use Python 3.12 for main tests
* Use `ubuntu-20.04` for Python 3.6 since it's been removed in `ubuntu-latest`
* Remove Python 2.7 since it's not supported by GitHub Actions anymore (https://github.com/actions/setup-python/issues/672)
* Add the missing `setup-python` step
* Merge the `pip install` commands
The `''` arg specifies a custom default value if the key isn't found. However, the default of `None` works fine for boolean testing:
```python
>>> 'gzip' in [None]
False
```
I missed this when I originally reviewed https://github.com/pallets-eco/flask-debugtoolbar/pull/154.
I took a quick peek at upstream to see if this has any backwards-breaking issues whereby we'd need to check the `werkzeug` version, but from my reading it looks it should be fine most of the time.
Also, this was deprecated back in April's `2.3.0` release and then removed in the recent `3.0.0` release, so I suspect most of our userbase will have already migrated to those versions.
Given this lib is a dev-tooling library not typically used in production, I'm not too worried about ensuring we support the 0.01% case where someone is using an old version of `werkzeug` + a custom charset.
More context:
* https://github.com/pallets/werkzeug/issues/2602
* https://github.com/pallets/werkzeug/pull/2641
* https://github.com/pallets/werkzeug/pull/2768
I started to cut a new release but realized it's a bit painful that we
are currently maintaining both a `CHANGES.rst` file and also tagging
releases in GitHub releases UI.
For a busy project, maintaining a dedicated changelog makes sense... but
the reality is this project is in maintenance mode, and we the
maintainers are more likely to cut releases when they're easy/low
friction. Since GitHub very nicely has the "Auto-generate-release-notes"
button, let's just use that.
I considered copy/pasting the results from that to `CHANGES.rst`, but
even that feels like a waste of time.
Replaced `_request_ctx_stack.top` with `request_ctx` per https://github.com/pallets/flask/pull/4682
This checks the version of `flask` and only does the switcheroo on newer versions of flask...
