Bug 2203139
Summary: | New release of sqlalchemy with many fixes and new orm | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | justin.lamp96 |
Component: | python-sqlalchemy | Assignee: | Nils Philippsen <nphilipp> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 38 | CC: | brian, infra-sig, mbayer, nphilipp, orion |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2023-11-16 14:45:21 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
justin.lamp96
2023-05-11 10:05:25 UTC
Fixing component (python3-sqlalchemy is EPEL-only) Any word or update on this issue? (In reply to Brian J. Murrell from comment #2) > Any word or update on this issue? Yes: SQLAlchemy version 2 is incompatible with other software using the 1.x APIs. Version 1.4 introduced the new API so it’s possible to write software that works with both. This unfortunately makes it impossible to introduce this new version in stable Fedora releases, too much would break. For Fedora 40, I intend to upgrade python-sqlalchemy to version 2.x and have a python-sqlalchemy1.4 compatibility package for software that needs the old stack. Among the dependents, we need to find out which is which, so the affected packages depend on the right package. This Fedora Change is tracked here: https://fedoraproject.org/wiki/Changes/SQLAlchemy_2 *** This bug has been marked as a duplicate of bug 2134559 *** > For Fedora 40, I intend to upgrade python-sqlalchemy to version 2.x and have a python-sqlalchemy1.4 compatibility package for software that needs the old stack.
I think that's a great idea. I would assume the two packages would be mutually exclusive since they use the same import space (this was an intentional, non-trivial decision on our part).
|