Expose the Android API level that python was built against, in sys.implementation as _android_api.
Purposes:
* Identify the platform as Android.
* Allow detecting a mismatch with the runtime sdk version returned by platform.android_ver() (bpo-26855), for example when the runtime sdk is lower than the built API level.

Patch added.

I don't think sys.implementation is a good place to contain the information of the underlying platform. By Doc/sys.rst:

An object containing information about the implementation of the currently running Python interpreter.

Sorry, it's Doc/library/sys.rst

I don't think sys.implementation is a good place to contain the information of the underlying platform.

Quite the opposite, the ndk API level gives an information about the implementation of the currently running Python interpreter saying that this Python has been built against this version of Android libc identified by this API level.

OK I see the rationale.

I woupd prefer to have a public attribute.

Typically, for other sorts of build configuration data, we have relied on extracting that from the ./configure-produced Makefile and making it available via sysconfig.get_config_var(). I think we should be cautious about bloating sys.implementation with platform-specific data unless there is an overriding need for it, for example, if it is needed during interpreter initialization before sysconfig can be initialized. If not, I'd look at adding the needed values as configuration variables in configure.ac.

@ned
The information that the interpreter is an Android built, is needed in bpo-16353 [1][2]. In msg266135, the corresponding patch adds the 'is_android' attribute to the already bloated sys module. I had thought then about using sysconfig.get_config_var() as you are suggesting, but this means that the os module would need now to import sysconfig on all linux platforms and build this big dictionary (about 650 entries on linux).

So it seems that the choice is between:
(1) adding an attribute (is_android or android_api) to the bloated sys module
(2) bloating sys.implementation with platform-specific data

I think that (2) would be better since _android_api is an information about the implementation, it tells that in these binaries, such and such features are available or not (bpo-26857 for example). The drawback is that it would not be documented except in Misc/NEWS [2].

@victor
Do you mean a public attribute of sys.implementation ?
Adding a new sys.implementation required attribute is described in PEP-421. In that case the attribute name could be 'libc_version' or 'libc'.

[1] msg175006 suggested another approach though, but this seems to be abandoned.
[2] For completeness, Stefan has submitted a feature request to google in msg266089.

Well, bpo-16353 has been entered upon attempting to fix bpo-16255 (see msg173477).

So an alternative exists. bpo-16353 could be closed as 'wont't fix'. The list of locations where '/bin/sh' is hard coded in the standard library in msg266084 shows that only the subprocess module and the test suite need to know the location of the system shell. So the subprocess module and bpo-27027 could deduct the location of this shell via sysconfig.get_config_var('android_api').

A patch to expose the Android API level in sysconfig.get_config_vars().

According to bpo-27453, do this minor change in the patch: s/$CC -E/$CPP $CPPFLAGS.

Here's an issue - there's already a macro called ANDROID_API defined in libcutils [1] If someone is going to integrate Python into AOSP, redefining macros may cause a problem.

[1] https://android.googlesource.com/platform/system/core/+/master/include/cutils/compiler.h#42

Integrating Python into AOSP does not make sense. The patch can be changed with s/ANDROID_API/ANDROID_API_LEVEL.

Yep adding Python to Android's build system is a rare case. Just to mention there's already an macro and avoiding possible redefined macros is always good.

New patch incorporating the substitutions to '$CPP $CPPFLAGS' and ANDROID_API_LEVEL.

+ @unittest.skipIf(sysconfig.get_config_var('ANDROID_API_LEVEL') == 0,
+ "not an android platform")

Hum, sysconfig.get_config_var() returns None for unknown variable. Why checking ==0?

@xavier: Are you generating the patch using "hg diff"? I don't see the base revision in your patch, and so there is no [Review] link on your patch.

In sysconfig.parse_config_h(), the variables in pyconfig.h that have a commented-out '#undef' line are set to 0. Fortunately, there is no Android API level 0.

Checking '== 0' ensures that autoreconf has been run to add '#undef ANDROID_API_LEVEL' to pyconfig.h.in. If this autoreconf step were to be missed, the test would (correctly) fail on the buildbots that are not Android as get_config_var() would return None then and the test would not be skipped and fail.

Most of the tests in the Python test suite do check 'not sysconfig.get_config_var()' instead, except:
Lib/test/test_cmath.py|543 col 22| @unittest.skipIf(sysconfig.get_config_var('TANH_PRESERVES_ZERO_SIGN') == 0, "system tanh() function doesn't copy the sign")
Lib/test/test_math.py|978 col 22| @unittest.skipIf(sysconfig.get_config_var('TANH_PRESERVES_ZERO_SIGN') == 0, "system tanh() function doesn't copy the sign")

Are you generating the patch using "hg diff"? I don't see the base revision in your patch, and so there is no [Review] link on your patch.

I am using 'hg diff' with ~/.hgrc set to 'git = on' and this time, naively removed the '--git' from the output of 'hg diff' instead of commenting out 'git = on' in the config file :(
(not finding any reference explaining why this setting is wrong for Rietveld). I will change that to have 'git = on' always commented out.

The Python Developer’s Guide in section '16.1. Minimal Configuration' recommends setting 'git = on'. Since we are switching to git shortly, it is probably not very useful to enter a new issue to update the Guide explaining that this setting must not be used when producing patches to be reviewed by Rietveld because the base revision is missing in this case.

I am using 'hg diff' with ~/.hgrc set to 'git = on' and this time, naively removed the '--git' from the output of 'hg diff' instead of commenting out 'git = on' in the config file :(

You don't need to do that. I've been using the same setting [1] for 5 years without having a single problem. If you have a fresh clone of https://hg.python.org/cpython/ and using the 'default' branch, you're good.

[1]

[diff]
git = True
showfunc = True
unified = 8

+ @unittest.skipIf(sysconfig.get_config_var('ANDROID_API_LEVEL') == 0,
+ "not an android platform")
+ def test_is_android(self):
+ # Use an heuristic, the shell on Android is at /system/bin/sh.
+ proc = subprocess.run(['/system/bin/sh', '-c', 'echo OK'],
+ stdout=subprocess.PIPE)
+ self.assertIn(b'OK', proc.stdout)

I dislike such functional test, it might fail and might need maintaince.

I suggest to push the change without the unit test.

@berker
This does not work for me.

I found an old discussion [1] on the git format problem with Rietveld. The thread diverges rapidly toward another subject, "submitting a branch instead of a patch to the issue tracker" but comes back to the original subject at the end. It seems that "not including the base changeset id in the --git diff is an oversight" of mercurial that has never been fixed.

[1] http://grokbase.com/t/python/python-dev/1135q4xxa8/hg-diff

I suggest to push the change without the unit test.
Agreed.

I did "hg pull -u" before re-generating the diff. Other than that, sometimes newer mercurial versions behave better (I have 2.8.2).

bpo-27442-3.patch: be careful, the new item in Misc/NEWS is not at the top of its section. Moreover, I still consider that the unit test is risky and not really needed (just remove it).

Good job, there is now a [review] button :-)

Good point about Misc/NEWS: I just regenerated the patch mindlessly to check the "diff --git" situation :)

Actually, Xavier, it's often better to leave out the NEWS section in the bug tracker patches and just add it before pushing. Perhaps Rietveld choked on the NEWS file before because it's constantly changing?

Thanks Berker and Stefan for your help on 'hg diff --git'. Yes Stefan, maybe your patch has a [review] button because Rietveld found that your patch applied cleanly against the head of the default branch at the time you have submitted it, so it could guess the base revision while mines were submitted late, or rather without a 'hg pull -u' right before the submission ?

I guess so. Our Rietveld setup apparently has some heuristics that work best when you're on the default branch and completely synced with the main repo.

New changeset 46567fda0b29 by Xavier de Gaye in branch 'default':
Issue bpo-27442: Expose the Android API level in sysconfig.get_config_vars()
https://hg.python.org/cpython/rev/46567fda0b29