Previously the custom theme was vendored in via a `git` submodule...
Now this theme is available via a python package, so install it using `extras_require` instead.
This also unlocks letting other tooling such as ReadTheDocs install the custom theme without having to do custom git incantations.
I also removed the `index_logo` config as Sphinx warns that it's not a supported option by the theme. I grep'd the theme package, and it makes no mention of this option, besides we were leaving it blank already, so there's no point in having it.
`pkg_resources` has been deprecated by `setuptools` for quite a while: https://setuptools.pypa.io/en/latest/pkg_resources.html
It's got some bugs/warts:
* https://github.com/pypa/setuptools/issues/2531
* https://discuss.python.org/t/will-setuptools-remove-pkg-resource-module-in-the-future/27182
So switch to using `importlib` functions which are part of the Python standard library as of `3.8`.
This is less error-prone, and also removes the need for `setuptools` to be installed in order for this panel to work.
I realize we technically still support `3.7`, but I thought it was fine to change this particular panel to require `3.8`, as `3.7` support is best effort given that it's now EOL'd by the core Python team.
I also removed the relative path location for specific libraries as it was simply blank for me on Python 3.12... I think showing the location of the site packages directory should suffice. If someone later wants to build this out further, they're more than welcome to.
Note that `importlib.metadata.distributions()` does have an outstanding issue that it reports a local editable install twice, but they plan to eventually fix that:
* https://github.com/pypa/setuptools/issues/4170
Bump to the latest versions of `jquery` and `jquery-migrate`.
I popped open the browser console and I see five deprecation warnings, but 3 out of the 5 are triggered by `jquery.tablesorter.js` which we vendor, so nothing we can do there.
The other two we should address, but we can do so in a follow-on PR as they are merely deprecations at this point, not fatal errors.
So getting onto the `3.x` series, even with deprecation warnings, is a nice step forward.
Previously we shipped the minified version of `jquery`, and we could
continue to do so, but given this is a dev tool and we still have
warnings we need to fix, I opted for the non-minified version for now.
Additionally, they offer a `slim` varient that is stripped down... we
could probably use that too, but I didn't take the time to investigate.
Fix: https://github.com/pallets-eco/flask-debugtoolbar/issues/166
This will allow us to migrate to the latest version of jquery 1.x series.
After we're on 1.9.x we can upgrade to the 3.x series.
I bumped this, and then checked the developer console while clicking
through the various panels offered in FDBT... Everything worked as
expected and I got zero warnings from `jquery-migrate`. So I think it's
safe to pull this in.
This is a pre-requesite to upgrading to the latest version of `jquery`,
as per their docs we have to first bump to `1.9+`, then bump the version
of `jquery-migrate`, then can bump to latest `jquery` version.
While I could do this in a single PR, I thought simpler to do it as a
series of PRs for easier reversion if we later run into problems.
Related:
* https://github.com/pallets-eco/flask-debugtoolbar/issues/166
Update to the latest `v2.31.3` version of this `jquery` plugin, which
unblocks upgrading to `jquery` >= `1.9.x`.
Using a fork because:
1. The original repo hasn't been updated in seven years: https://github.com/christianbach/tablesorter
2. The most recent committer to the original repo ☝️ now maintains the fork.
3. The fork was updated just a few months ago.
4. The fork supports the latest versions of `jquery`:
> Works with jQuery 1.9+ (`$.browser.msie` was removed; needed in the original version)
As far as I can tell, no other changes are needed.
This is a straight copy/paste of the non-minized code from: https://github.com/Mottie/tablesorter
I used non-minimized for simplicity, since this is a dev-only tool, the
perf impacts of minimization don't really matter.
I tested this manually by:
```shell
$ cd flask-debugtoolbar/test
$ flask --app basic_app run --debug
```
Then loading `http://127.0.0.1:5000/` in a recent version of Chrome and
finding a FDBT panel that uses the sorter. In this case, the SQLAlchemy
panel. I visually compared behavior pre/past upgrade and it appeared
identical.
Related:
* https://github.com/pallets-eco/flask-debugtoolbar/issues/166
I noticed some trailing whitespace has crept into these files. It wasn't caught by `pycodestyle` because that only checks Python files.
Ideally we'd add a linter that catches these, but I didn't want to take the time to configure one right now, I just want my editor to stop flagging these while I'm working on trying to upgrade `jquery` versions.
Long term, we'll probably want a meta-linter like `prettier` or whatever the newest kid on the block is.
The `flask.__version__` attr is deprecated and will be removed in the Flask 3.1 version. This PR replaced this attr to `importlib.metadata.version`.
We could remove the use of `pkg_resources` when we drop the Python 3.7 support.
Running on Python 3.12 I see:
```shell
[2024-04-11 11:01:12,915] WARNING in toolbar: Disabled flask_debugtoolbar.panels.versions.VersionDebugPanel due to ImportError: import_string() failed for 'flask_debugtoolbar.panels.versions.VersionDebugPanel'. Possible reasons are:
- missing __init__.py in a package;
- package or module path not included in sys.path;
- duplicated package or module name taking precedence in sys.path;
- missing module, class, function or variable;
Debugged import:
- 'flask_debugtoolbar' found in '/Users/jeffwidman/Code/open-source/flask-debugtoolbar/src/flask_debugtoolbar/__init__.py'.
- 'flask_debugtoolbar.panels' found in '/Users/jeffwidman/Code/open-source/flask-debugtoolbar/src/flask_debugtoolbar/panels/__init__.py'.
- 'flask_debugtoolbar.panels.versions' not found.
Original exception:
ModuleNotFoundError: No module named 'distutils'
```
This is because Python 3.12 removed `distutils`.
Fix pulled from https://bugs.python.org/issue41282#msg393018.
This will not work on Python `3.6`, but we've already dropped support for that.
After the fix, the error is gone and the Versions panel re-appears.
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
