Posts: 492
Joined: Dec 2006
Reputation:
5
2011-01-19, 13:47
As most people here know, there is a version of python that compiles with xbmc codebase. Also, it's my understanding that there is a general desire to remove this and depend on an instance of python built for the various systems.
I wanted to get this discussion started since the work I've been doing with SWIG for supporting plugin's in other programming languages (besides python) is anticipating this removal.
Currently the build in my fork is simply hacked to remove the code "thunks" that provide the entry points into the python library and a straight link to the system installed python shared library. This causes several script incompatibilities which I mentioned in a previous post and which are fairly straightforward to deal with (spiff has been putting pressure on the script developers to not code to these outdated assumptions - e.g. the 'os' module can handle path values with the "special:" prefix).
I would like to start working on this but before I started I wanted to know how people envision this working - keeping in mind that python 2.x will (hopefully) not be the only basis for writing plugins going forward so whatever is done with the embedded python should be able to be generalized (i.e. "generalised" for the UK readers :-) ) to other scripting languages.
Thanks in advance for any ideas.
Jim
Posts: 12,706
Joined: Nov 2003
Reputation:
129
spiff
Team-Kodi Member
Posts: 12,706
work is underway, there's a ticket for win32, which is the main showstopper atm. we would use any python 2.x library supplied on the system.
Posts: 492
Joined: Dec 2006
Reputation:
5
Thanks spiff,
I'm guessing your response assumes a straightforward approach - dynamically linking the codebase and making the given platform support the dependency.
I was wondering if there's a way to supply the shared library in a plugin itself and rely on the (a?) dependency mechanism in xbmc to pull down an appropriate version of (say) python (or another scripting language).
Going a step further, is there a way to isolate the symbol spaces from two similar libraries (say python 2.x and python 3.0) so that one plugin could run against one, and another plugin against the other in the same process space? I'm not familiar enough with the hand coding of dynamic library loading (especially in platforms outside of linux) to know whether this is doable.
Possibly c-pluff might help here?
Posts: 11,582
Joined: Feb 2008
Reputation:
84
davilla
Retired-Team-XBMC Developer
Posts: 11,582
OSX platfrom can also support the removal of internal python BUT that must wait until it's build system is brought up to date with the project I'm working.
In that project, the depends on macports is removed and OSX side builds any required depends as a pre-step. This includes python as we support several versions of OSX and cannot depends on what is provided as on some platforms, AppleTV in particular do not have any "system" python at all.
So on OSX, python can be "system" with respect to what xbmc uses, but it's really compiled and packaged into the app container and becomes transparent regarding xbmc usage.
In essence, OSX builds will become a cross-compile that can target any OSX SDK from 10.4 (which we target now in a hacked way) to 10.6 and beyond.
Posts: 12,706
Joined: Nov 2003
Reputation:
129
spiff
Team-Kodi Member
Posts: 12,706
yes, i plan to extend the add-on installer using package-kit on linux, while windows/osx will ship binaries. the interpreters will be separate add-ons, listed as a dependency.
Posts: 1,165
Joined: Jan 2009
Reputation:
2
CrashX
Posting Freak
Posts: 1,165
Can you clarify how this would work for scripts ( programs like Navi-X ) which require direct access to xbmc gui ?
The normal XBMC log IS NOT a debug log, to enable debug logging you must toggle it on under XBMC Settings - System or in advancedsettings.xml. Use
XBMC Debug Log Addon to retrieve it.
Posts: 1,165
Joined: Jan 2009
Reputation:
2
CrashX
Posting Freak
Posts: 1,165
2011-01-20, 22:38
(This post was last modified: 2011-01-20, 22:54 by CrashX.)
I am just curious on how much more work needed to support scripts vs plugins ? If you can provide more details how the new scripts (programs) would interact with gui when python becomes binary addon ?
The normal XBMC log IS NOT a debug log, to enable debug logging you must toggle it on under XBMC Settings - System or in advancedsettings.xml. Use
XBMC Debug Log Addon to retrieve it.
Posts: 492
Joined: Dec 2006
Reputation:
5
Nothing will change when python itself is loaded as a binary-addon. It's just a dynamic means for loading the python engine itself as a shared library (rather than linking directly against it). In order to support any number of other scripting languages, it's important to decouple python from the codebase and allow it to be "plugged in" along with support for these other scripting languages so that each will have uniform and consistent means of being managed.
From the perspective of a python script/plugin writer, nothing will change. The same interface will be presented to the script writer.
How that interface is implemented gets more interesting if the running plugin/scripts are in their own process spaces (though I agree with davilla - one step at a time).