expose the Android API level in sysconfig.get_config_vars()

[xdegaye]

BPO	27442
Nosy	@vstinner, @ned-deily, @skrah, @xdegaye, @berkerpeksag, @yan12125
Files	android_api.patch android_api_2.patch android_api_3.patch issue27442-3.patch: regenerated android_api_3.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/xdegaye'
closed_at = <Date 2016-07-09.09:09:29.464>
created_at = <Date 2016-07-02.14:52:55.319>
labels = ['type-feature', 'library']
title = 'expose the Android API level in sysconfig.get_config_vars()'
updated_at = <Date 2016-07-09.09:09:29.463>
user = 'https://github.com/xdegaye'

bugs.python.org fields:

activity = <Date 2016-07-09.09:09:29.463>
actor = 'xdegaye'
assignee = 'xdegaye'
closed = True
closed_date = <Date 2016-07-09.09:09:29.464>
closer = 'xdegaye'
components = ['Library (Lib)']
creation = <Date 2016-07-02.14:52:55.319>
creator = 'xdegaye'
dependencies = []
files = ['43610', '43622', '43636', '43660']
hgrepos = []
issue_num = 27442
keywords = ['patch']
message_count = 29.0
messages = ['269716', '269717', '269719', '269720', '269721', '269724', '269726', '269748', '269756', '269757', '269807', '269828', '269829', '269832', '269834', '269878', '269902', '269937', '269938', '269954', '269958', '269962', '269963', '269980', '269981', '269982', '270008', '270013', '270031']
nosy_count = 7.0
nosy_names = ['vstinner', 'ned.deily', 'skrah', 'xdegaye', 'python-dev', 'berker.peksag', 'yan12125']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue27442'
versions = ['Python 3.6']

[xdegaye]

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.

[xdegaye]

Patch added.

[yan12125]

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.

[yan12125]

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

[xdegaye]

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.

[yan12125]

OK I see the rationale.

[vstinner]

I woupd prefer to have a public attribute.

[ned-deily]

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.

[xdegaye]

@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.

[xdegaye]

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').

[xdegaye]

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