[HenrikDK]

Hi, I'm not quite sure how this external python support in eden's supposed to work, but we're currently working on some modifications for the youtube plugin that would greatly benefit from the availability of python 2.7. But eden pre seems to ship with python 2.6, is there any way to change this?

[TobiasTheCommie]

One very specific problem we are having is finding a windows compatible way to do os.kill.

I haven't been able to find any usable windows version. Nor have i been able to find any that will work for 64bit. But os.kill should work in python 2.7.

All other solutions i have found look really really bad.

[topfs2]

Well, with eden the idea is that we use the one available on the system. So its more up to the distro than us.

If we will add hooks for addons to specify so that it only works on a very specific python version I'm not sure, it makes sense however to have that (and perhaps we have).

Maverick for example have 2.6.6 so it's probably safer to assume it's >= 2.6.x if you want to hit all possible users.

[linuxluemmel]

Well, with eden the idea is that we use the one available on the system. So its more up to the distro than us.

Maverick for example have 2.6.6 so it's probably safer to assume it's >= 2.6.x if you want to hit all possible users.

@topfs2

Does this mean that the next relase will not have a python system build
into xbmc ?

[TobiasTheCommie]

Well, with eden the idea is that we use the one available on the system. So its more up to the distro than us.

If we will add hooks for addons to specify so that it only works on a very specific python version I'm not sure, it makes sense however to have that (and perhaps we have).

Maverick for example have 2.6.6 so it's probably safer to assume it's >= 2.6.x if you want to hit all possible users.

Adding specific hooks doesn't solve our problem, since we can't make a workaround for windows(only windows with less than 2.7 is the problem) in python 2.6.6

Another solution would be to have xbmc.getInfoLabel( "Window.Property(DialogDownloadProgress.IsAlive)" ) not crash constantly(which it does and makes it unusable) AND make getSetting setSetting thread safe(so, one thread can save a setting, sleep. another thread changes setting. First thread load the setting after sleep. with the proper changes from both thread.

That would actually be my preferred solution. Right now i am creating 3 files in the temp directory(two of them lock files) just to workaround this issue.

And windows can't remove the stale lock files(mac and linux can).

I really really hate the lock files.

[HenrikDK]

Well, with eden the idea is that we use the one available on the system. So its more up to the distro than us.

If we will add hooks for addons to specify so that it only works on a very specific python version I'm not sure, it makes sense however to have that (and perhaps we have).

Maverick for example have 2.6.6 so it's probably safer to assume it's >= 2.6.x if you want to hit all possible users.

So if i understand correctly, if we specified a v 2.7.x dependency in the plugin, this would require the user to know how to fetch and install this, even on windows?

My main problem with this is that it's probably gonna work great on linux and osx since they seem to have relatively upto date python distributions. But on IOS and Windows this would cause far more problems.

[topfs2]

@linuxluemmel

It means we use system libraries instead of building our own.

@TobiasTheCommie
@HenrikDK

This is the point of dependencies, if you have a dependency on 2.7 then its hidden on systems without 2.7. Much like if you have a dependency on the webserver (we don't have a specific dep for this yet, so merely as a point) you shouldn't see addons which extend or depend on the webserver.

@TobiasTheCommie

They should be threadsafe afaik, if they aren't please bug report that. It shouldn't depend on the python version if its safe or not, our API should always be thread safe (I know it most likely ain't but without bug reports we might miss them).

@HenrikDK
And both windows and IOS are most likely to have recent versions of python as the packager controls the version. On linux the distro does

[TobiasTheCommie]

They should be threadsafe afaik, if they aren't please bug report that. It shouldn't depend on the python version if its safe or not, our API should always be thread safe (I know it most likely ain't but without bug reports we might miss them).

I'll make a small plugin that shows this error case and submit a bug report.

[topfs2]

I'll make a small plugin that shows this error case and submit a bug report.

Thanks, feel free to cc me on the ticket

[WiSo]

Windows ships with python 2.6.6 because it was decided to use the same version as Linux does. If we skip that we can move to 2.7.

[JFweigh]

Is there no way to select a different python install under Eden? I am running ubuntu hardy (and cannot upgrade due to hardware restrictions) on my main XBMC box. I understand it's not a good idea to upgrade the system python past 2.5 due to various dependencies so have created a seperate 2.6 install which should meet my needs hoping to be able to point XBMC pre Eden at this.

P.S. How does XBMC decide what is the system python? As an experiment I created a symlink so that typing python from the terminal runs 2.6 instead of 2.5 but my add on still reports 2.5.2.

Thanks for any help.

[topfs2]

Is there no way to select a different python install under Eden? I am running ubuntu hardy (and cannot upgrade due to hardware restrictions) on my main XBMC box. I understand it's not a good idea to upgrade the system python past 2.5 due to various dependencies so have created a seperate 2.6 install which should meet my needs hoping to be able to point XBMC pre Eden at this.

P.S. How does XBMC decide what is the system python? As an experiment I created a symlink so that typing python from the terminal runs 2.6 instead of 2.5 but my add on still reports 2.5.2.

Thanks for any help.

you would need to alter the linker and pkg-config paths so that when your compiling pre-eden it will prefer 2.6.