Skip to content

toolchain: auto resolve deps#3271

Merged
kuzeyron merged 2 commits into
kivy:developfrom
T-Dynamos:minor-fixes
Jan 25, 2026
Merged

toolchain: auto resolve deps#3271
kuzeyron merged 2 commits into
kivy:developfrom
T-Dynamos:minor-fixes

Conversation

@T-Dynamos

@T-Dynamos T-Dynamos commented Dec 13, 2025

Copy link
Copy Markdown
Member

Closes #3274

Package resolution is performed using the hostpython's pip via the --dry-run option.

Example

requirements = python3,
    kivy==master,
    materialyoucolor,
    materialshapes,
    exceptiongroup,
    asyncgui,
    asynckivy,
    android,
    pillow==11.0.0,
    pycairo,
    https://github.com/kivymd/KivyMD/archive/master.zip,
    trio,
    openai

Output:
image

@T-Dynamos T-Dynamos changed the title [WIP] toolchain: auto resolve deps toolchain: auto resolve deps Dec 13, 2025
@T-Dynamos T-Dynamos changed the title toolchain: auto resolve deps toolchain: auto resolve deps Dec 13, 2025
@T-Dynamos
T-Dynamos force-pushed the minor-fixes branch 7 times, most recently from 87f16ae to 7152f01 Compare December 20, 2025 11:40

@AndreMiras AndreMiras left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome work, looks good overall, pretty clear and nice feature thank you!
I just have a few remarks and concerns I'd like to discuss.

  1. It would be nice to have at least some basic unit tests for is_wheel_platform_independent() (that one should be relatively easy) and process_python_modules() (that one is more tricky, but let's try to have at least some basic coverage). I noticed the code currently bypasses the new logic when recipe_build_order is a Mock - having proper tests would let us remove that workaround.
  2. Have we thought of having a --no-auto-resolve or something like that for reproducible builds?
  3. A bit tricky to integration test, I imagine that would mean having an app build with the requirements list not fully defined/pinned and test it runtime, but then we have some build reproducibility concerns. Do you have some ideas for how to make sure your changes don't get broken later on without us realising?

Comment thread pythonforandroid/build.py Outdated
Comment thread pythonforandroid/build.py Outdated
@T-Dynamos
T-Dynamos marked this pull request as draft January 23, 2026 17:45
@T-Dynamos

Copy link
Copy Markdown
Member Author

@AndreMiras

A bit tricky to integration test, I imagine that would mean having an app build with the requirements list not fully defined/pinned and test it runtime, but then we have some build reproducibility concerns. Do you have some ideas for how to make sure your changes don't get broken later on without us realising?

I think an integration test would be overkill here. The modules list is highly variable, and all of this work is handled by pip itself.

@T-Dynamos
T-Dynamos marked this pull request as ready for review January 23, 2026 19:34

@AndreMiras AndreMiras left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK let's go :)

@kuzeyron
kuzeyron merged commit 1fc0269 into kivy:develop Jan 25, 2026
43 checks passed
@T-Dynamos T-Dynamos mentioned this pull request May 23, 2026
5 tasks
PhaedrusFlow added a commit to qompassai/fieldsnek that referenced this pull request May 26, 2026
Kivy 2.3.1 ships pre-generated Cython C that calls _PyLong_AsByteArray
with 5 args. Python 3.14 added a 6th `with_exceptions` parameter, so
buildozer dies during the Cython extension compile with:

    error: too few arguments to function call, expected 6, have 5
    note: '_PyLong_AsByteArray' declared here (... 6 params)

The p4a project tracked this in kivy/python-for-android#3274 and shipped
the auto-resolve recipe in PR #3271; on the user side, the documented
fix is to use Kivy master (which is built with Cython >= 3.1 that emits
the new 6-arg call) plus p4a develop + API 36 + NDK r29.

Changes:
- buildozer.spec: kivy==2.3.0 -> kivy==master; android.api 34 -> 36;
  android.ndk 25b -> 29; android.sdk 34 -> 36; comment block rewritten
  to document the new tested combination.
- build.sh: auto-resolve ANDROIDNDK from $ANDROID_SDK_ROOT/ndk/29.*;
  auto-detect buildozer in ~/venv_p4a_develop/bin first (the venv
  Buildozer docs require for the Python 3.14 path); ANDROIDAPI 34 -> 36;
  NDKAPI 21 -> 26; ANDROIDNDKVER 25b -> 29.
- docs/ANDROID_BUILD.md: rewrite \u00a71 (pre-flight) for the python3.14 venv
  install; \u00a72 (SDK) for platform 36 / build-tools 36 / ndk r29; \u00a74
  (build) to source the venv first; expanded troubleshooting table
  with the _PyLong_AsByteArray entry and links to upstream issues.

Refs:
- https://buildozer.readthedocs.io/en/latest/installation/
- kivy/python-for-android#3271
- kivy/python-for-android#3274
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Python 3.14 Android build failures: _remote_debugging_module and SDL2 bootstrap (pyconfig.h missing)

3 participants