[jfcarroll]

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

[spiff]

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.

[jfcarroll]

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?

[davilla]

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.

[jfcarroll]

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

Is it possible to move this dependency (on, say, python, or whatever) from a compile time dependency to a run time dependency? For example, if I install a plugin that's written in python, only then would the appropriate python library (maybe 2.x, maybe 3.0) be installed as a dependent plugin.

The same thing would work for other scripting languages, from a Jvm or perl or tcl, etc. That would create a minimal xbmc install and it would expand as necessary.

The only piece I'm not sure of how to accomplish is the management of hand loaded shared libraries symbols so that dependencies can be satisfied even when the same symbol occurs in multiple shared libraries.

An analogy in java would be class loader isolation (if you're familiar with java) or OSGI.

[spiff]

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.

[davilla]

Is it possible to move this dependency (on, say, python, or whatever) from a compile time dependency to a run time dependency? For example, if I install a plugin that's written in python, only then would the appropriate python library (maybe 2.x, maybe 3.0) be installed as a dependent plugin.

It's possible, you would have to purge xbmc core of all python refs, headers and such. Move that to an binary addon. With python you do have path issues so that python 'knows' where to find it's bits.

[jfcarroll]

It's possible, you would have to purge xbmc core of all python refs, headers and such. Move that to an binary addon. With python you do have path issues so that python 'knows' where to find it's bits.

Actually, it's almost there. In my fork the python hooks are largely isolated and minimized (and generated with SWIG). The XBPy**** classes look like they were in the process of being moved into a binary addon (cpluff) and I need to generalize them anyway to finish what I'm working on.

I'm also thinking about possibly isolating plugins into separate process spaces (someone recommended this before). This would really make the addon system really flexible but might come at the cost of performance (and more work). Thoughts?

[davilla]

Actually, it's almost there. In my fork the python hooks are largely isolated and minimized (and generated with SWIG). The XBPy**** classes look like they were in the process of being moved into a binary addon (cpluff) and I need to generalize them anyway to finish what I'm working on.

I'm also thinking about possibly isolating plugins into separate process spaces (someone recommended this before). This would really make the addon system really flexible but might come at the cost of performance (and more work). Thoughts?

I'm always a big fan of walking into complicated re-factoring. Maybe binary addon for python first, then think about/do isolation.

[CrashX]

Can you clarify how this would work for scripts ( programs like Navi-X ) which require direct access to xbmc gui ?

[jfcarroll]

Can you clarify how this would work for scripts ( programs like Navi-X ) which require direct access to xbmc gui ?

I'm not sure exactly what you're referring to, but anything that currently works in python should continue to work (perhaps with some minor modifications) whether the plugin/scripting system becomes a binary addon, or if it (eventually) ends up isolated in its own process space.

Are you asking for the details of how either of these things would be accomplished?

Jim

[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 ?

[jfcarroll]

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