[Mobile-sig] python on android

Fetchinson . fetchinson at googlemail.com
Thu Jan 29 17:45:05 CET 2015

On 1/29/15, Guido van Rossum <guido at python.org> wrote:
> Can we stop arguing about Kivy vs Toga and focus on the one thing that they
> have in common, the need for a working Python 3 port on Android and iOS
> (for a start)? This is apparently mostly a matter of solving a lot of small
> things with the build system, dependencies, improved config files, and
> getting stuff integrated upstream so it can be built out of the box, right?

I think so. And even better would be if binary android or iOS packages
are distributed on python.org just like for windows and people don't
have to compile themselves since even if the source tree is perfectly
okay and can be compiled for android or iOS the actual compilation
will be complicated for an average user of (and not developer of) a
python program on a phone.

> After that the layers 2-4 stuff can compete, but everybody wins when layer
> 1 is dealt with (even imperfectly).

Exactly. All the layers 2-4 stuff from various approaches would use
the same layer 1 stuff just as various GUI toolkits on desktop use the
same python core distribution. I understand from Russell that hardware
integration on the phone is tricky and is definitely separate from
layer 1, so all the fancy phone related hardware stuff can live in
competing packages. But a core python (layer 1) should be there for
all developers to count on.


> It's pretty sad that nobody apparently
> knows how to reproduce the build steps, and everybody just copies the one
> Python 2.7.{1,2} binary that someone built out of sheer willpower.
> On Wed, Jan 28, 2015 at 8:04 PM, Russell Keith-Magee <
> russell at keith-magee.com> wrote:
>> Hi Bill,
>> On Thu, Jan 29, 2015 at 10:41 AM, Bill Janssen <janssen at parc.com> wrote:
>>> Russell Keith-Magee <russell at keith-magee.com> wrote:
>>> >  b) I don't like the Kivy build tools. They're a lot more complex than
>>> they
>>> > need to be.
>>> I didn't find it troublesome, but of course this wasn't my first rodeo.
>>> I'd certainly agree it's not a push-button solution.  So, what would a
>>> less complex system be like?
>> A less complex system is what Toga does.
>>  1. You use cookiecutter to generate a stub project. This gives you the
>> full source tree for a project you can load into XCode (iOS), or build
>> with
>> ant (Android), including a "hello world" __main__.py
>>  2. You download the pre-compiled Python.framework for iOS, or libPython
>> for Android, and copy it into a libs directory
>>  3. You start writing Python code, replacing the __main__.py with your
>> own
>> logic.
>>  4. You compile and deploy your project using XCode/ant.
>> Compare this with Kivy - My experience was spending a couple of days
>> getting the Kivy build process to actually work - trying to find versions
>> of the Android NDK that aren't being distributed any more (but are the
>> only
>> hard coded options in the build system), working out that the provided
>> code
>> doesn't work with the most recent versions of Cython, and sourcing
>> libraries for all sorts of dependencies, so that I could compile SDL and
>> a
>> bunch of OpenGL stuff - none of which I needed. It took me a couple of
>> days
>> to get to "hello world" - and all because of something that could have
>> been
>> shipped as a pre-compiled binary.
>>> > I'm going to guess the Kivy people are all Linux users, because
>>> > they don't appear to have worked out that binary compatibility is a
>>> thing.
>>> Sorry -- why is that a Linux thing?
>> If I want to distribute an app for OS/X or Windows, I give you an
>> executable, and It Just Works (tm). Source *might* be provided as an
>> option
>> in the interest of being open source, but it's not how you distribute
>> anything in practice. The "Linux way" for distribution is to distribute
>> source, and tell you to compile it yourself. Distributing binaries is an
>> afterthought, because ABI compatibility makes building and distributing
>> binaries painful. Most projects don't have the infrastructure to
>> distribute
>> binaries for multiple platforms, so unless you can get the OS to provide
>> a
>> recent binary for you, you compile from source.
>> I see reflections of that bias here. Even though ABI compatibility exists
>> for both iOS and Android as platforms, Kivy chooses to distribute as
>> source.
>>> > You don't need to have every user compile Python and the rest of the
>>> Kivy
>>> > stack - you can just ship a binary library, and it will work on every
>>> phone
>>> > with the same hardware (I know, because Toga does this. The Toga
>>> > bootstrapping process is "clone this repo, and copy this file". You
>>> could
>>> > reduce this to "clone this repo" if you were happy putting binary
>>> artefacts
>>> > into version control.)
>>> Sure.
>>> >  c) Kivy's build tools are Python 2.7.1 only on iOS, and 2.7.2 on
>>> Android;
>>> I believe the mobile platform packaging tools are still stuck at 2.7.
>>> Kivy 1.8+ will run on Python 3 on desktop, though.
>> Yes - but in practice, the absence of Python 3 on Mobile means that Kivy
>> on Mobile is Python 2 only, and an old version at that.
>>> > and if you build them on OSX, when you're on the device, they report
>>> > sys.platform as "darwin".
>>> Seems like a bug; I imagine you're suggesting that the Kivy build
>>> process should patch that file to return "android"?  Although I never
>>> know what to look at to get that platform info correctly -- this is a
>>> larger Python issue.
>> Yes, it's a bug (or at least a missing feature). The build system patches
>> that Kivy use doesn't introduce anything for targeted builds (i.e., using
>> an x86 platform to compile ARM64 binaries - which is what you're doing
>> when
>> you compile for mobile), and doesn't provide a platform definition for
>> mobile.
>>> And kivy.utils.platform seems to return the proper thing.
>> So... instead of they've introduced their own way to get access to
>> information that Python already has a standard way of providing.
>>> > Going back to my post
>>> For those of you following along at home, here's Jeff's list (I had to
>>> go and look it up).
>> Jeff?
>>> >  1. A library build of Python
>>> >  2. Templates to stub out a working Python project
>>> >  3. Libraries to do bridge between native language environments and
>>> Python
>>> >  (for me, that's Rubicon)
>>> >  4. Libraries for utilising native system services (for me, that's
>>> > Toga)
>>> > - I agree with Kivy on layer 1, and I was able to use
>>> > their build tools to bootstrap my own. However, I have very different
>>> > opinions on layers 2-4.
>>> Just to outline the Kivy approach to 2-4: Kivy doesn't really do 2 -- it
>>> provides examples, and you're supposed to extrapolate from them.  I
>>> guess that's a form of template.  For #3, there's Kivy's "pyjnius" (to
>>> access Java via JNI) (https://github.com/kivy/pyobjus) and "pyobjus" (to
>>> access Objective-C via runtime reflection)
>>> (https://github.com/kivy/pyjnius).  For #4, as I said, there's "plyer"
>>> (https://github.com/kivy/plyer).
>> I'd also include most of Kivy in #4 as well, because that's how they're
>> tackling the widget issue.
>> We can have a separate discussion sometime about Django vs. Tornado :-).
>> So - a monkey knife-fight at dawn, then :-)
>> Yours,
>> Russ Magee %-)
>> _______________________________________________
>> Mobile-sig mailing list
>> Mobile-sig at python.org
>> https://mail.python.org/mailman/listinfo/mobile-sig
> --
> --Guido van Rossum (python.org/~guido)

Psss, psss, put it down! - http://www.cafepress.com/putitdown

More information about the Mobile-sig mailing list