We currently use a forked copy of pip 20.1 with many changes. The following have already been fixed upstream:

• Recognizing the android platform tag, so that e.g. building for an android_25 platform will accept wheels tagged as android_21.

• As of pip 25.3, all sdists, whether they have a pyproject.toml or not, are now built using PEP 517. The --no-build-isolation option still exists, but there's no realistic use case for that in Chaquopy. So we no longer need to bundle setuptools and wheel, and we can remove any patches connected to running setup.py directly.

• Miscellaneous fixes, especially compatibility with newer versions of Python.

The following have not been fixed upstream:

• Correct interpretation of environment markers in requirements:

  • Modify pip handling to use platform tag for iOS. beeware/briefcase#2101
  • Determining cross-platform resolution strategy pypa/pip#13111
  • Various package-index filtering flags do not affect the environment markers pypa/pip#11664

  python_version (and data-requires-python) will no longer be an issue once we require a matching buildPython version (#991, #1295). sys_platform and the others might be possible to handle with a cross venv, as Briefcase does on iOS, or cibuildwheel does for both iOS and Android. This has recently been broken out into the beeware/xbuild project.

• Disabling the implicit --only-binary mode when using --platform. This may not be necessary anymore if we switch from --platform to a cross venv (see above).

  Briefcase on iOS isn't affected by this because it uses --only-binary all the time, but it still receives occasional complaints about pure-Python packages which don't provide wheels. Chaquopy has a larger user base, so forcing --only-binary may be too much of a regression.

• Preferring older native wheels over newer sdists. Removing this will make it more difficult to install a couple of our packages, so I've recorded this in #1417.

• Making any attempt to build native code fail fast and cleanly. This is done with monkey patches to setuptools which are inserted into both isolated and non-isolated builds – our bundled copy of setuptools is unmodified. However, non-setuptools build systems are becoming increasingly popular, so we should try to come up with a more general solution. For example, we're already setting a few environment variables like CC to nonexistent paths – maybe we could point them at actual scripts which would give a better error message.

• Some custom error messages, which could probably be moved to the Gradle plugin or the pip_install script with only a small loss of detail, or maybe just abandoned.

  • See notes in Add support for Python version 3.14 #1350.
  • “To see full details in Android Studio” message may also no longer be useful, since Android Studio jumps to the first error message in the output, which probably comes from pip.

• Updates to distlib to make it less strict about metadata parsing. If this has not been fixed upstream, we might want to consider removing pip_install's dependency on distlib and taking a different approach.