Bug 2367955

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!

I’ll investigate.

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.

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

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!

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.

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.