Add a basic integration test that ensures the python package is installable

[jeffwidman]

We need a basic sanity test that installing the python package doesn't feel like it did in:

• https://github.com/pallets-eco/flask-debugtoolbar/pull/225

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.

Ideally this gets run under all the versions of python we support, so that if some import works under a newer python but not an older python that gets caught as well.

I assume we can use pip install -e . to install the package from the local copy, as we want to test the tip of the PR branch, and not what's available on PyPI.

[jeffwidman]

@greyli is ☝️ something you want to tackle?

Looks like you've already written a chunk of the scaffolding in that other repo, so would only need to port it over to here.

[nickjj]

Yep, I like the idea of this. The --editable flag (-e) lets us do a local install, I've used it in other packages.

There's also https://test.pypi.org/ if we really wanted a full blown end to end test. It could be used once in a while if we're testing to see how certain package details get displayed on PyPi. You can also configure pip to install from the test repo to ensure a package "really" installs successfully too.

[jeffwidman]

The one problem for automating anything against test.pypi.org is since it's a clone of pypi.org, and pypi.org doesn't let you ever upload another copy of a given version, then it's tough to use it for automated testing because every upload after the first one will fail.

I normally use it for manual testing before the final push to pypi.org. In fact I even manually uploaded it yesterday before pushing the real release live, that's when I realized we'd forgotten to increment the version number. I just didn't think to also do a manual sanity install or I would have caught the bug.

[greyli]

@greyli is ☝️ something you want to tackle?

Sure, I will create a PR today or this weekend.

[greyli]

Created #230.

It's enough to run this test against the latest Python version. This test only needs to handle the situation when the used library is not defined in the install_requires list. If an import statement works in the latest Python but not the old ones, the existing unit tests will catch it.