[Mobile-sig] python on android

[Russell Keith-Magee]

On Tue, Mar 3, 2015 at 9:23 AM, Wes Turner <wes.turner at gmail.com> wrote:

>
> http://maemo.org/community/maemo-developers/identifying_platform_in_python_code/
>
> Maemo sys.platform is linux2
>
True - but Maemo also isn't a "supported out of the box" platform for
Python, is it? Maemo might support and/or provide Python, but Python
doesn't *officially* support Maemo - there's nothing in the Python tree
that is maemo specific AFAICT. To me, that means that either Maemo is
genuinely indistinguishable from a desktop Linux box, or they're patching
Python's source tree in some way for a Maemo-specific build.

It's also possible that this sys.platform identifier is an accident, rather
than intention. As evidence of this - if you use the Python 2.7.2 sources
that Kivy provides for Android, and you build the Python library on OS/X,
sys.platform reports as "darwin". This is *clearly* wrong - but Python
itself works, as long as you don't try to use anything sys-dependent. In
the Maemo case, the "linux" answer could be accidental, reflecting the
easiest solution they could get working, rather than a specific intention
to label the platform as linux.

Either way, I don't think that the decisions of someone outside the Python
source tree can be cited as an absolute example for what Python itself must
do.

>
> http://lipyrary.blogspot.com/2011/09/python-and-linux-kernel-30-sysplatform.html?m=1
>
> The correct check would be sys.platform.startswith linux
>
> If the check is for which libc, sys.platform is the wrong differentiator
>
> If the check is for PATH, sys.platform is the wrong check
>
I'm uncertain what you're arguing here. A sys.platform.startswith check
will absolutely help you pick up 'linux', 'linux2' and 'linux3' - but won't
help you tell desktop Linux apart from Android.  What check are you
proposing a the "I'm on android" check as an alternative to sys.platform ==
'android'?

> Arguably, a patch for android is not yet ready if [...]
>
Agreed - but a patch is close (AFAICT, resolving autoconf issues is the
only serious hurdle remaining), and this issue of "what does sys.platform
return" is a technical issue that needs to be resolved before a patch is
completed and proposed for trunk.

Yours,
Russ Magee %-)



> On Mar 2, 2015 7:14 PM, "Russell Keith-Magee" <russell at keith-magee.com>
> wrote:
>
>>
>> On Sun, Mar 1, 2015 at 9:38 AM, Wes Turner <wes.turner at gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, Feb 28, 2015 at 5:35 PM, Russell Keith-Magee <
>>> russell at keith-magee.com> wrote:
>>>
>>>>
>>>> On Sat, Feb 28, 2015 at 10:07 AM, Wes Turner <wes.turner at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Feb 27, 2015 at 6:40 PM, Russell Keith-Magee <
>>>>> russell at keith-magee.com> wrote:
>>>>>
>>>>>> [...] and, IMHO, a specific platform module for Android (as I've said
>>>>>> previously in this forum, I don't believe an Android device should identify
>>>>>> as "Linux", or iOS as "Darwin", because those identifiers are misleading on
>>>>>> mobile devices).
>>>>>>
>>>>>>
>>>>> re: sys.platform and mobile platforms
>>>>>
>>>>> iOS is not built on a Darwin kernel. Android is built on a Linux (3)
>>>>> kernel.
>>>>>
>>>>> For android, I think sys.platform="linux2" makes sense for things like
>>>>> pathlib (which, I assume, checks sys.platform) largely because *most*
>>>>> things should be linux-compatible (if mostly read-only and SELinux MAC
>>>>> controlled). Otherwise, many existing libraries would need to be
>>>>> unnecessarily patched.
>>>>>
>>>>
>>>> Sure - Android is a lot more "linux-like" than iOS is "Darwin-like";
>>>> however, there are still a lot of differences. You can't assume /usr/bin is
>>>> populated with all the usual utilities, and that they are executable with
>>>> Popen, for example.
>>>>
>>>
>>> The existence of executables in $PATH is not a fair assumption from
>>> either os.name or sys.platform.
>>> (see: distutils.spawn.find_executable (!), sarge).
>>>
>>
>> Sure. My point is that if you actually have a Linux box, you can assume
>> you have a PATH, and you can assume the existence of /bin, /usr/bin, and
>> it's probably reasonable to assume the existence of a bunch of basic Unix
>> utilities that will behave in predictable Unix ways. That isn't a
>> reasonable assumption for Android.
>>
>> Plus, I only gave popen/spawn as one example; it isn't the only platform
>> related issue. My personal use case is widget toolkits - if you're on a
>> desktop Linux machine, the native widget toolkit is probably GTK+ or Qt; if
>> you're on Android, it's the native Java widgets.
>>
>> The core of my point - Android may use a Linux kernel, but to say Android
>> "is just a Linux" is a massive oversimplification. Any code that made that
>> assumption would almost certainly need to have a second level "if Android
>> else..." check anyway.
>>
>> Looking at other precedents in the source tree - there's a different
>> platform backend for each AIX, FreeBSD and IRIX *version*. I'll wager the
>> difference between FreeBSD 5 and FreeBSD 6 are much less significant than
>> the differences between a desktop Linux and Android.
>>
>>
>>>
>>>> IMHO, it would still be a lot more helpful to differentiate "linux2"
>>>> from "android" at the sys.platform level. Yes, this means existing
>>>> libraries etc may need to be patched. However, I don't see that as a bad
>>>> thing. Verifying that a package actually works on mobile, rather than just
>>>> assuming it will, seems like a prudent approach to me.
>>>>
>>>
>>> This is a hard question. Without reasonable build environments, it's
>>> very unlikely that anyone will have the resources to test on these other
>>> platforms (and architectures); so things could be arbitrarily broken when
>>> they would otherwise work. Arguably, this is the responsibility of
>>> end-developers.
>>>
>>>  I think android sys.platform should read as linux2 (even for GNU/Linux
>>> kernel 4.0+); but have no expertise with iOS.
>>>
>>
>> For me, it's not about build environments; it's about the original
>> developer of a third-party Python app being aware of the requirements of a
>> mobile platform, and opting in to supporting them.
>>
>> As soon as you have functionality than needs to be platform aware, you
>> need to (in theory) support all possible platforms that Python supports.
>> Lets say I've written a library that does a sys.platform==linux2 check;
>> that library will fail for anyone with AIX, or HPUX, or FreeBSD, or any of
>> the other supported *nix platforms that exist. The developer needs to
>> opt-in, and say "yes, we also support AIX" (or whatever); I'd argue that
>> the differences between Desktop linux and Android are such that this
>> "opt-in" is a process that is worthwhile enforcing.
>>
>> For me, the question comes down to this: Is it reasonable to assume that
>> a piece of code that works on a desktop Linux will automatically work
>> out-of-the-box with Android? Your position appears to be that it *is* a
>> reasonable assumption; my experience to date has been that this isn't the
>> case. The fact that significant patches are needed to the stock Python
>> source tree in order to get it to compile for Android supports my position.
>>
>> And even if I'm wrong, and Android==Linux2 *is* a reasonable assumption -
>> there are still some cases where it's necessary to differentiate between
>> desktop Linux and Android, so some sort of "am I on Android?" check is
>> going to be needed.
>>
>> My argument is that given that this check is going to be needed, why
>> invent something new? Why not just use "sys.platform == 'android'", and
>> accept that third party developers using sys.platform will need to make a
>> small change to support this new platform, once they've established that
>> their code will actually run on Android - or make whatever changes are
>> necessary to support the differences that exist.
>>
>> Yours,
>> Russ Magee %-)
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/mobile-sig/attachments/20150303/b04e5597/attachment.html>