Changes/SQLAlchemy 2

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

The python-sqlalchemy package is upgraded to major version 2. A compatibility package python-sqlalchemy1.4 is added to the distribution to cater for software which doesn’t yet use the new API, this can be installed side-by-side. Other packages using SQLAlchemy are identified and, if necessary, steps are taken to ensure they use the correct major version package.

Owner

Name: Nils Philippsen, Čestmír Kalina
Email: nphilipp -at- redhat.com, ckalina -at- redhat.com

Current status

Targeted release: Fedora Linux 40
Last updated: 2023-08-22
discussion thread
FESCo issue: <will be assigned by the Wrangler>
Tracker bug: <will be assigned by the Wrangler>
Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

The major version 2 of SQLAlchemy was released early 2023, it contains many useful new features. It breaks compatibility with version 1.4 in many ways, this version is available in Fedora Linux and used by about 40-50 packages today. Version 1.4 allows using the new API so programs can accommodate both major versions, but how many of the packages using SQLAlchemy in Fedora have been adapted accordingly is unknown at this point, this needs to be determined. A parallel-installable compatibility package python-sqlalchemy1.4 will most likely need to be added to the distribution and packages not yet using the new API will have to be changed to use the new API or use this package instead for the time being.

Feedback

Benefit to Fedora

Version 2 of SQLAlchemy has new features including:

deep integration with PEP 484 typing practices and current capabilities, particularly within the ORM, allowing e.g. to build ORM models declaratively using Python type annotations
fully ORM-integrated approach to bulk INSERT that is typically an order of magnitude faster on most backends

See the upstream release announcement for details.

Scope

The proposal owners have to upgrade python-sqlalchemy to the new major version and add the compatibility package to the distribution. They need to find out which of the existing packages in Fedora Linux don’t work with the new version and document how they need to be packaged differently to actually use the compatibility package.

Other maintainers of packages using SQLAlchemy need to verify if their packages work with the new version of SQLAlchemy and, if not, do the necessary changes to:
- make them compatible with the new API, or
- ensure that the compatibility package is installed and also used by the code during runtime.

This change isn’t expected to require involvement of release engineering, it just involves a number of dependent packages high enough to make it impractical to get all their maintainers on-board as proposal owners.

Policies and guidelines: N/A (not needed for this Change)

Trademark approval: N/A (not needed for this Change)

Alignment with Community Initiatives: M/A

Upgrade/compatibility impact

Upgrades would be subject to the potentially changed dependencies between packages, but this should be straightforward and have no compatibility issues.

How To Test

No special hardware or data is needed for testing.
Testers would need to install packages using SQLAlchemy and use them.
Installing the packages should pull in the “right” version, i.e. the default one with the new major version, or the compatibility package.
Using the packages should show no problems, neither on the command line nor in logs or similar.

User Experience

Users using packages already adapted to the new APIs, they should benefit from the new features, including performance enhancements.

Dependencies

A quick scan(*) on Fedora 38 for packages requiring the provides of python3-sqlalchemy yields this list of potentially affected dependent RPM source packages:

bodhi-server
buildbot
datagrepper
dionaea
dlrn
eralchemy
ipsilon
keylime
limnoria
mailman3
mirrormanager2
module-build-service
OpenLP
pagure
pgadmin4
pychess
python-agate-sql
python-aiomysql
python-alembic
python-databases
python-datanommer-models
python-flask-security-too
python-flask-sqlalchemy
python-gertty
python-hass-data-detective
python-migrate
python-odata-query
python-opentelemetry-contrib
python-oslo-db
python-pybids
python-pykmip
python-repoze-who-plugins-sa
python-sentry-sdk
python-sqlacodegen
python-sqlalchemy-collectd
python-sqlalchemy-filters
python-sqlalchemy_schemadisplay
python-sqlalchemy-utils
python-wtforms-sqlalchemy
python-zope-sqlalchemy
resalloc
sigul
yokadi

(*) using this command:

rpm -q --provides python3-sqlalchemy | while read prov rest; do
    dnf repoquery --qf '%{sourcerpm}' --whatrequires "$prov"
done | \
    sed 's|-[^-]*-[^-]*$||g' | \
    grep -vFx python-sqlalchemy | \
    sort -u

Contingency Plan

Contingency mechanism: (What to do? Who will do it?) Proposal owners would have to revert to version 1.4 of SQLAlchemy, dependent packages aren’t expected to have to revert applied changes.

Contingency deadline: Beta Freeze
Blocks release? No

Documentation

Release Notes

SQLAlchemy was upgraded to version 2 in this release of Fedora Linux with many new features and a revamped API. A compatibility package was put in place to ensure software that depends on the old API stays functional.

Search