On Wed, Dec 31, 2014 at 12:58 AM, Chris Barker firstname.lastname@example.org wrote: >
On Mon, Dec 29, 2014 at 10:39 PM, Wes Turner email@example.com wrote:
As far as Kivy goes - I have tinkered with Kivy; I've even used Kivy's tools as a starting point for some of my own efforts. However, to me, Kivy is focussing too far up the stack - their toolchain appears to be based on getting Kivy working on mobile, not Python. This is an entirely reasonable approach if Kivy is what you want at the end of the day - but it's not what I want. I've been taking a much more atomic approach. The Kivy toolchain is also anchored in old versions of Python 2; something that definitely needs to be addressed.
IIUC, how Kivy works is not to put a python interpreter on the platform, but rather to run all your code through Cython, creating a C program that used the python runtime as a library, essentially. So there is no python code involved at run time.
Incorrect. On both iOS and Android, Kivy uses Cython as the mechanism to get a C-native platform binding (PyJNIus/PyObjCus) that allows your Python code to invoke native libraries directly. The deployed app is a Python interpreter that is packaged with all the Python code and libraries, and it's executed as byte code at runtime.
Toga/Rubicon takes a similar approach, but using ctypes directly, instead of using Cython.
So the Kivy lib aside, is this a good way to go on Mobile? I can't image it's too hard to remove the kivy UI stuff if you don't want to use it -- even if the current tools all include all that by default.
Sure, it could be done. And in a sense, that is what I'm doing - taking all the Kivy-specific parts out of Kivy's tools. And what I've been left with is things that, IMHO, should be in Python's own source tree. Along the way, I've discovered all the ways that Kivy's tools are deficient (for example, as a result of the way they've done their build, sys.platform reports the compilation platform, not the runtime platform).
But is it better to target getting Python running on Mobile just like it
does on the desktop: you have a python interpreter, a bunch of python modules, and you bundle it all up with a executable launcher of some sort, al la py2exe, py2app, etc.?
That approach might work. However, py2app etc are just optimisations - you still need to have all the language bindings etc.
On top of that, on Android, the end product must essentially be a JAR file. Jython doesn't currently work on the Dalvik VM, so there's a whole other level of tooling required. This might be changing with Android 5/Lollipop - I've only had a brief look at the VM changed in Android 5.
Something to keep in mind is that that way most Python code is run may not make sense (or even be an option with Apple's rules, anyway): you have a python environment installed, and install a bunch of application code on top of that, and run that. Makes sense to system scripts, and web apps and that like, but really doesn't make sense for "Apps".
What I'm getting at is that the final goal for what exactly we want people to be be able to distribute may effect decisions about what to build and how to build it.
However, at the core, an "app" is just iOS/Android are running a process. Just as on desktop or web, that process can, if you so choose, start a Python interpreter and run a script. It's just a set of instructions.
Yes, those instructions need to play nice with your local platform conditions, but that's no different to the distinction between desktop apps and web apps - I've spent plenty of time on the Django-users mailing list teaching newcomers to the web that you can't just take a long lived process and treat a web request as a button click starting that process - you need to restructure your code to take into account the short lived, stateless nature of HTTP requests.
As for the "Apple" factor - that's not an issue (at least, not at the moment). Apple doesn't place restrictions on "interpreted" apps in the app store, as long as the scripts are all bundled as part of the app (i.e., you can't deliver updates/enhancements by sending an installed app a new script to run). There are Kivy apps in the App Store right now. Of course, this is subject to the whims and fancies of Apple, but this has been a stable policy for a couple of years, and I suspect there would be a riot if this policy were to change substantially, because it's central to the operation of many games engines.
BTW, one thing I'd like to be able to build is what I call a "BILS"
(Browser Interface, Local Server) app: you run a web server bundled up in an app that points itself to the browser component for all the UI. We've been very successful doing this on Windows and OS-X, as a way to provide a self contained desktop app, and a hosted Web App with almost entirely one code base, and an identical user interface.
(Python / Pyramid on the back end, desktop is the local browser hosted by a wxPython wrapper)
We'd like to be able to port that to iOS and Android, but there doesn't appear to be a solid python option that we could run a Pyramid web server on Mobile at this point -- maybe I'm wrong)
I'm aware of the approach - I've even used it myself in the past (to get a UI on an old iPaq handheld). However, once you've got a working Python interpreter on mobile with good bindings to the underlying platform, it shouldn't be too hard to write - getting a WebKit view that consumes the entire screen is easy to write, no matter what platform you're on, so then you just need to set up the server stuff, and for that all you need is a Python interpreter with a working socket and threads module. I'm not sure it would be great for battery life, but that's a separate problem.
I can't say that particular approach something I'm particularly interested in myself, but my point is that this shouldn't matter - once you can do Python on mobile, it's up to you to decide what works or doesn't. But the first step is getting Python supported on mobile.
Yours, Russ Magee %-)