Skip to content

fix: restrict Python version to <3.13 to avoid tiktoken build failure#453

Open
octo-patch wants to merge 1 commit into666ghj:mainfrom
octo-patch:fix/issue-311-python-version-constraint
Open

fix: restrict Python version to <3.13 to avoid tiktoken build failure#453
octo-patch wants to merge 1 commit into666ghj:mainfrom
octo-patch:fix/issue-311-python-version-constraint

Conversation

@octo-patch
Copy link
Copy Markdown

Fixes #311

Problem

pyproject.toml declares requires-python = ">=3.11" without an upper bound, implying Python 3.13 is supported. However, the camel-ai==0.2.78 dependency pins tiktoken==0.7.0, which has no pre-built wheels for Python 3.13 and requires a Rust compiler to build from source. This results in a confusing build error with no clear explanation of the root cause.

Solution

Add an explicit upper bound <3.13 to the requires-python constraint in backend/pyproject.toml. This causes package managers (uv, pip) to immediately report a clear incompatibility error when Python 3.13 is used, instead of failing deep inside a Rust compilation step.

Testing

  • Verified the constraint change is accurate: camel-ai==0.2.78tiktoken==0.7.0 has no Python 3.13 wheels
  • The fix matches the behavior described by the bot in npm run dev, unable to start the mirofish #311 (Python ≤3.12 required)

@dosubot dosubot bot added the size:XS This PR changes 0-9 lines, ignoring generated files. label Apr 3, 2026
koyouko added a commit to koyouko/MiroFish that referenced this pull request Apr 6, 2026
- fix(runner): prevent action data loss from partial line reads (666ghj#460)
  Track safe_position; only advance past newline-terminated lines to
  avoid permanent data loss when the writer is mid-flush.

- fix(build): restrict Python to <3.13 to avoid tiktoken failure (666ghj#453)
  tiktoken wheels are not available for Python 3.13+.

- fix(security): default FLASK_DEBUG to False (666ghj#445)
  Debug mode was on by default, exposing the Werkzeug debugger in
  production deployments on 0.0.0.0.

- fix(polling): stop frontend polling when backend fails (666ghj#448)
  Step2 and Step3 now detect failed status and error-count limits,
  stopping the polling interval instead of looping indefinitely.

- fix(simulation): stop Step2 hanging after prepare failures (666ghj#336)
  Reset state flags on each prepare run; raise ValueError instead of
  returning silently so the task manager marks the task as failed.

Co-Authored-By: koyouko <koyouko@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:XS This PR changes 0-9 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

npm run dev, unable to start the mirofish

1 participant