Android pip upstreaming

[mhsmith]

Our current patches are mainly for:

• Recognizing the android platform tag, so that e.g. building for an android_25 platform will still accept wheels tagged as android_21.
• Preferring older native wheels over newer sdists. I left a comment in the pip patch explains why we don't simply use --prefer-binary, but I'm not sure whether that still applies.
• 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.

We also try to make any attempt to build native code fail fast and cleanly, but think that's done only with patches to setuptools, not pip.

Once we're able to use an unpatched version of pip, we should stop bundling it with Chaquopy, and instead install it into a cached venv during the build, as build-wheel does. For reproducibility, we should still use a fixed version of pip by default, but it would be a good idea to provide a pip { version } option to override this.

Related:

• 980

[IsakTheHacker]

Will the pip upstreaming render the current package repository obsolete?

[mhsmith]

No, because Android wheels aren't yet accepted by PyPI, although that's something we're working on long-term. But I'd like to be able to use an unpatched version of pip to install from our existing repository, because the patches make it more difficult to upgrade pip to deal with issues like https://github.com/beeware/briefcase/issues/1480.