Bug 2367955 - Please branch and build python-fastapi in EPEL 10
Summary: Please branch and build python-fastapi in EPEL 10
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: python-fastapi
Version: 42
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Ben Beasley
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 2367957 2367961
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-05-22 10:23 UTC by Enrique
Modified: 2025-05-31 02:12 UTC (History)
3 users (show)

Fixed In Version: python-fastapi-0.115.12-3.el10_1
Clone Of:
Environment:
Last Closed: 2025-05-31 02:12:20 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Enrique 2025-05-22 10:23:31 UTC
Please branch and build python-fastapi in EPEL 10.

I would like to request a python package for fastapi (https://fastapi.tiangolo.com/) similar to the existing packages in Fedora (python3-fastapi).

I know for EPEL 8/9 this wasn't really feasible (#2092953). I hope a more recent stack now in EPEL 10 would make that possible. At least python-pdm-backend is now in EPEL 10, but I don't know about other dependencies.

Reproducible: Always

Comment 1 Enrique 2025-05-22 10:55:30 UTC
I think that for fastapi-slim probably everything is there. For the +all version I have identified that at least jinja2 and markupsafe are missing and created new tickets (https://bugzilla.redhat.com/show_bug.cgi?id=2367961 https://bugzilla.redhat.com/show_bug.cgi?id=2367957).

Thanks!

Comment 2 Ben Beasley 2025-05-22 11:26:35 UTC
I’ll investigate.

Comment 3 Ben Beasley 2025-05-22 14:58:36 UTC
python-fastapi (bootstrap build)
  -> python-pydantic-extra-types: I can branch this as co-maintainer.
     -> python-pendulum: we can omit the pendulum and all extras instead of branching this
     -> python-phonenumbers: we can omit the phonenumbers and all extras instead of branching this
     -> python-pycountry: we can omit the pycountry and all extras instead of branching this
     https://src.fedoraproject.org/rpms/python-pydantic-extra-types/pull-request/18

If you need to use the extra Pydantic types provided by pydantic-extra-types[pendulum], pydantic-extra-types[phonenumbers], and/or pydantic-extra-types[pycountry], then you can request EPEL10 branches of python-pendulum, python-phonenumbers, and/or python-pycountry, respectively, and we can enable those extras in python-pydantic-extra-types. Otherwise, I’d rather not ask for branches of things for which I’m not a primary maintainer and which we perhaps don’t really need.

Then once I have a bootstrap build of python-fastapi:

python-fastapi (non-bootstrap build)
  -> fastapi-cli: I can branch this as primary maintainer
     -> python-rich-toolkit: I can branch this as primary maintainer
        - Backport to EPEL10 by reverting declarative pyproject buildsystem
          and disabling tests that require python-inline-snapshot (which
          turns out to be all of them)
        -> python-typing-extensions >= 4.12.2:
           This is a hard one, as python3-typing-extensions-4.9.0-6.el10 is in RHEL10
           (BaseOS). It turns out that with the older Pydantic release 2.9.2 in EPEL10
           (newer versions also blocked on typing-extensions), we can *apparently*
           loosen this version bound. Import-only “smoke tests” succeed, at least.
           https://tiny.distro.builders/view-rpm--view-c10s--python3-typing-extensions.html 
  -> python-sqlmodel: I can branch this as primary maintainer

This seems like a reasonable plan, and it all tested well in local mock builds.

One caveat is that, once I get FastAPI branched into EPEL10, you can expect that I will have a very limited ability to update it in the future, either because of dependency version requirements, or because FastAPI upstream introduces small backwards-incompatible changes relatively regularly, and I can’t ship incompatible updates in EPEL under https://docs.fedoraproject.org/en-US/epel/epel-policy-updates/ without seeking and adequately justifying an explicit policy exception. That’s one reason that I chose not to python-fastapi until someone asked for it.

Comment 4 Fedora Update System 2025-05-22 16:17:43 UTC
FEDORA-EPEL-2025-810fc990a4 (fastapi-cli-0.0.7-3.el10_1, python-fastapi-0.115.12-3.el10_1, and 3 more) has been submitted as an update to Fedora EPEL 10.1.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-810fc990a4

Comment 5 Enrique 2025-05-22 17:22:01 UTC
Thank you very much for the effort! I am not sure whether our project needs the extra pydantic types to be honest. I will check on that.
I understand that it will be difficult to update fastapi, but I guess that's also a good thing, since it will remain stable, which is what we need (at least for a couple of years).

Thanks again!

Comment 6 Fedora Update System 2025-05-23 04:28:27 UTC
FEDORA-EPEL-2025-810fc990a4 has been pushed to the Fedora EPEL 10.1 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-810fc990a4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 7 Fedora Update System 2025-05-31 02:12:20 UTC
FEDORA-EPEL-2025-810fc990a4 (fastapi-cli-0.0.7-3.el10_1, python-fastapi-0.115.12-3.el10_1, and 3 more) has been pushed to the Fedora EPEL 10.1 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.