mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-06 02:48:13 -05:00
[GH-ISSUE #18349] feat: Can you pleases support python 3.13? #34098
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @stefaneidelloth on GitHub (Oct 15, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/18349
Check Existing Issues
Problem Description
I tried to install open-webui via pip for python 3.13 and got
ERROR: Could not find a version that satisfies the requirement open-webui (from versions: none)Then I saw in the documentation that python 3.11 is required and I don't have it available.
Desired Solution you'd like
=> Can you please support python 3.13?
Alternatives Considered
No response
Additional Context
No response
@silentoplayz commented on GitHub (Oct 15, 2025):
Python 3.12 is also supported FWIW. Related comment - https://github.com/open-webui/open-webui/issues/13970#issuecomment-2909349503
@Classic298 commented on GitHub (Oct 15, 2025):
Please check for existing issues!!!!
And it's not possible yet because some dependencies we depend on still aren't on python3.13
@stefaneidelloth commented on GitHub (Oct 15, 2025):
I did search for "python 3.13" in the open issues:
https://github.com/open-webui/open-webui/issues?q=is%3Aissue%20state%3Aopen%20python%203.13
@Classic298 commented on GitHub (Oct 16, 2025):
@stefaneidelloth Please also search in the closed issues:
There are a dozen issues related to this: https://github.com/open-webui/open-webui/issues?q=sort%3Aupdated-desc%20is%3Aissue%20python%203.13
@stefaneidelloth commented on GitHub (Oct 16, 2025):
@Classic298 Maybe you want to keep one of them open as kind of a placeholder/landing place, until the issue actually has been resolved? Even if you cannot do much about it except from maybe monitoring the dependencies that are still blocking the step.
@Classic298 commented on GitHub (Oct 16, 2025):
@stefaneidelloth
Appreciate the suggestion, but we have to keep the distinction between "open issue" and "closed issue" meaningful for the project.
An open issue signals that there's something broken or missing in Open WebUI itself that the maintainers are actively tracking and working to resolve.
In this case (python 3.13 support), we can't do much. The problem sits with third-party dependencies that haven't released Python 3.13 wheels yet. Keeping an issue open when we're fundamentally blocked by external factors and can't take action doesn't help anyone. It just adds noise to the backlog and eats our time.
Practically speaking, maintaining dozens of open "waiting for dependency X to release" issues becomes completely unmanageable. We'd spend time fielding duplicate requests and triaging things we have no control over instead of focusing on actual bugs and features. The search for closed issues already works perfectly fine.
Users searching "python 3.13" will immediately find all the existing issues and discussions (discussions should also be searched!) and understand exactly why it's not working. That's a better outcome than burying the real issue context under a constantly-active placeholder.
We do monitor what's blocking us, but we do it through dependency tracking, not through open GitHub issues. When dependencies update, the solution becomes obvious and someone will likely file a new issue or attempt a fix.
Until then, keeping it closed keeps the signal-to-noise ratio healthy for everyone working on the project.
Otherwise, maintaining hundreds of open issues for feature requests and issues that we have no direct control over becomes a management-nightmare and eats everyone's time without providing any real benefit.
@traumschule commented on GitHub (Oct 19, 2025):
Glad i found this. Thanks for the excellent explanation @Classic298! Some ops can't or don't take the time to research the whole story.
Did you see the milestone feature to track the "Python 3.13 migration"? Would be good to have a complete list of dependencies that need to support / funding to upgrade. #13137 also seems to require it.
For the time being see this and downgrade python or try docker for ease.
Added PR #18423
@rgaricano commented on GitHub (Oct 19, 2025):
Edited: I forgot some libs, ...I'll update
Libraries and Python 3.13 Compatibility:
FastAPI (
fastapi>=0.118.0):Uvicorn (
uvicorn[standard]>=0.37.0):Pydantic (
pydantic>=2.11.9):python-multipart (
python-multipart>=0.0.20):itsdangerous (
itsdangerous>=2.2.0):python-socketio (
python-socketio>=5.13.0):python-jose (
python-jose>=3.4.0):cryptography:
cryptographypackage is usually quick to support new Python versions. Check here for details.bcrypt (
bcrypt>=5.0.0):argon2-cffi (
argon2-cffi>=25.1.0):PyJWT (
PyJWT[crypto]>=2.10.1):authlib (
authlib>=1.6.3):requests (
requests>=2.32.5):aiohttp (
aiohttp>=3.12.15):async-timeout:
aiocache:
aiofiles:
starlette-compress (
starlette-compress>=1.6.0):httpx (
httpx[socks,http2,zstd,cli,brotli]>=0.28.1):starsessions (
starsessions[redis]>=2.2.1):SQLAlchemy (
sqlalchemy>=2.0.38):Alembic (
alembic>=1.14.0):Peewee (
peewee>=3.18.1):Peewee-migrate (
peewee-migrate>=1.12.2):pycrdt (
pycrdt>=0.12.25):redis:
redislibrary should support Python 3.13. Verify on their GitHub.APScheduler (
APScheduler>=3.10.4):RestrictedPython (
RestrictedPython>=8.0):loguru (
loguru>=0.7.3):@rgaricano commented on GitHub (Oct 19, 2025):
Edited: I forgot some libs, ...I'll update
I checked the libraries listed on PyPI to see their “Requires Python” or exhibited support for newer Python versions like 3.13.
I couldn’t find explicit “>=3.13” for all of them, but many show builds or statements that indicate compatibility.
Here’s a summary for the ones I found:
PyPi.org Table:
py3wheels)cp3.13wheels for 3.13@athoik commented on GitHub (Oct 19, 2025):
I suggest that we need that feature, re-opened and milestoned for 0.7.0!
Debian 13 / Trixie already comes with Python 3.13.
Ubuntu 25 already comes with Python 3.13.
I guess other (modern) distros are already switching to Python 3.13, so it's better to keep track of what is keeping us behind.
@rgaricano commented on GitHub (Oct 19, 2025):
Pypi.org dependent libs meta Requires python version:
(This is shorter in descriptions because I did with script)
Script that read requirements.txt and search in pypi:
check_pypi_compatibility.py
@athoik commented on GitHub (Oct 19, 2025):
We need to upgrade python-jose to 3.5.0.
Currently it's pinned on 3.4.0
@rgaricano commented on GitHub (Oct 19, 2025):
(cogito:14b with web search generated response)
I'll perform a deeper check for each library by visiting their repositories or official documentation. Here's the detailed analysis:
Confirmed Compatible:
Conclusion:
All libraries in your list appear to be compatible with Python 3.13 based on their respective repositories and documentation. However, for mission-critical applications, it's recommended to:
If you encounter any specific issues during testing, you can reach out to the respective library maintainers for support.
@athoik commented on GitHub (Oct 19, 2025):
Packages that need attention:
chromadb https://github.com/chroma-core/chroma/issues/5643
unstructured https://github.com/Unstructured-IO/unstructured/issues/3949
https://github.com/Unstructured-IO/unstructured/blob/main/CHANGELOG.md#01619
@athoik commented on GitHub (Oct 19, 2025):
Trying to run dev environment under Debian 13.
Issue with unstructured
Solved by updating unstructured to 0.18.15
Issue with rapidocr-onnxruntime
Installed using --ignore-requires-python, since there is no newer version than 1.4.4 to solve the issue.
The installation goes on, no other failures during install.
Then once starting backend it fails to import the pyaudioop.
And that one can be solved by installing the missing audioop (and not trying the fallback to pyaudioop from pydub).
... and now it runs under python 3.13
Now needs testing and few patches to address above mentioned issues.
@rgaricano commented on GitHub (Oct 19, 2025):
@athoik
I run Open-WebUI in python 3.12 with all libs updated to last version without problems.
@athoik commented on GitHub (Oct 19, 2025):
Regarding rapidocr-onnxruntime a ticket was created: https://github.com/RapidAI/RapidOCR/issues/579
Regarding pydub, several ticket exists: https://github.com/jiaaro/pydub/pull/816 , https://github.com/jiaaro/pydub/pull/841 unfortunately it seems the package is not maintained any more. So a workaround is to add
audioop-ltson our requirements.Regarding Open-WebUI, packages needed bump PR'ed: https://github.com/open-webui/open-webui/pull/18430 https://github.com/open-webui/open-webui/pull/18424
So it's not that hard to get an initial working Python 3.13.
Closing tickets doesn't help.
Taking actions... does move things forward.
@athoik commented on GitHub (Oct 20, 2025):
Regarding the
rapidocr-onnxruntimewe need to switch torapidocrSeaching on Open-WebUI code, I did manage to trace the requirement back to https://github.com/open-webui/open-webui/pull/1050
It seems that we are adding
rapidocr-onnxruntimein order to get OCR support to classPyPDFLoaderfromlangchain_community.We are currently using
langchain_community==0.3.29, but even updating to latest version 4.0, still uses oldrapidocr-onnxruntimeHere is the related code:
d259483e0d/libs/community/langchain_community/document_loaders/parsers/images.py (L100-L114)And here is a small program I made that uses both old rapidocr_onnxruntime and rapidocr.
The results, seem the same...
So, we need to create a PR on langchain_community.
Update from rapidocr-onnxruntime to rapidocr on langchain_community.
Update OpenWebUI to latest langchain_community and switch to rapidocr.
I'll keep informing about the progress here.
@stefaneidelloth please re-open ticket. Let's track progress here.
@athoik commented on GitHub (Oct 20, 2025):
PR created on langchain_community: https://github.com/langchain-ai/langchain-community/pull/375