Claude Code
c1c5bc3b5a
Investigation-only, cherry-picked from mikebridge's test/verify-sqlalchemy-continuum branch (backend-relevant hunks only, skipping unrelated frontend formatting drift). Bumps sqlalchemy to 2.0.51 and flask-sqlalchemy to 3.1.1 directly, rather than the FSA 3.0.5 intermediate step attempted in PR #42542. Notable fix beyond the version bumps: pessimistic_connection_handling (superset/utils/core.py) now calls connection.rollback() after its pool-checkout health-check SELECT. Under SQLAlchemy 2.0's autobegin behavior that SELECT implicitly opens a transaction it previously never closed, which is a plausible mechanism for the MySQL lock-wait-timeout symptom from the original #42542 break. Also updates two migration scripts (2018-07-26 add_implicit_tags, 2022-04-01 new_dataset_models_take_2) to Mapped[] typed relationship annotations -- these define their own standalone declarative models and were missed by discussion #40273's earlier unit-test-driven deprecation-warning sweep, since migration scripts aren't exercised by that suite. Removes the now-obsolete SQLALCHEMY_WARN_20 pytest.ini filterwarnings error lines, since sqlalchemy.exc.RemovedIn20Warning doesn't fire (or exist in the same form) once SQLAlchemy 2.0 is actually installed. Pushing to get a real test-sqlite/test-mysql CI signal, since local sqlite runs don't reliably reproduce the original break either way.
Python dependency logic
In this folder, the .in files, in conjunction with the ../pyproject.toml file (in the root of the repo) are used to generate the pinned requirements as .txt files.
To alter the pinned dependency, you can edit/alter the .in and pyproject.toml files, and then run the following command:
./scripts/uv-pip-compile.sh
:::warning
The pinned dependencies are based on the current version of python supported in Superset.
Output of ./scripts/uv-pip-compile.sh may vary slightly based on the python version you are using to run the command.
Check the pyproject.toml file for the current version of python supported.
:::
This will generate the pinned requirements in the .txt files, which will be used in our CI/CD pipelines and in the Docker images.
We recommend to everyone in the community to use the pinned requirements in their local development environments, to ensure consistency across different environments, though we don't force requirements as part of our python package semantics to allow flexibility for users to install different versions of the dependencies if they wish.
Note that development.txt is a superset of what's in base.txt, and all version numbers for shared library should fully match at all times. translations.txt is meant as a supplemental file to be used in conjunction with the other requirements files, and is not meant to be used standalone.