DeprecationWarning: os.getcwd() currently lies to you

A bug [1] was reported against the Ted plugin for Eden, saying that it fails to run. Part of the log was provided to me:

[INDENT]15:21:17 T:5872 NOTICE: [PLUGIN] 'TED Talks: version 2.3.0b1' initialized!
15:21:18 T:5872 ERROR: C:\Program Files\XBMC\system\python\Lib\multiprocessing\process.py:25: DeprecationWarning: os.getcwd() currently lies to you so please use addon.getAddonInfo('path') to find the script's root directory and DO NOT make relative path accesses based on the results of 'os.getcwd.'
ORIGINAL_DIR = os.path.abspath(os.getcwd())
15:21:18 T:5960 DEBUG: ------ Window Init (DialogBusy.xml) ------
15:21:18 T:5872 ERROR: C:\Program Files\XBMC\system\python\Lib\tempfile.py:162: DeprecationWarning: os.getcwd() currently lies to you so please use addon.getAddonInfo('path') to find the script's root directory and DO NOT make relative path accesses based on the results of 'os.getcwd.'
dirlist.append(_os.getcwd())
15:21:19 T:4112 INFO: Loading skin file: DialogProgress.xml[/INDENT]

I'd really appreciate some help here as I am new to xbmc and also don't have access to a Windows machine.
1) Is this error actually fatal or not? It says "DeprecationWarning" but is logged as an ERROR - I thought they were fatal, but OTOH we appear to have two from a single run.
2) I don't see it on Linux (built from Eden beta 3 source). Shouldn't this DeprecationWarning log on all platforms to allow these issues to be caught during development?
3) What am I supposed to do about it? Both the lines of logging come from python libs (is xbmc fetching these from the ether on demand?) - do the libs need to be tweaked by someone?
4) Shouldn't there be a trace?

Many thanks for reading this.

[1] https://github.com/moreginger/xbmc-plugi...s/issues/5

Do exactly as it says to grab the addon path

Instead of using:

Use:

This msg displays on all platforms I've seen

Eldorado Wrote:Do exactly as it says to grab the addon path

Instead of using:

Code:

os.getcwd

Use:

Code:

addon.getAddonInfo('path')

This msg displays on all platforms I've seen

This is not happening in the addon but the Python modules that the addon is importing(multiprocessing and tempfile)

Probably need some tweaking to the warning to not be affected by the Python modules(probably should post a Ticket on Trac)


Moreginger - these are just warnings(for the time being) they should still function properly.

giftie Wrote:This is not happening in the addon but the Python modules that the addon is importing(multiprocessing and tempfile)

Probably need some tweaking to the warning to not be affected by the Python modules(probably should post a Ticket on Trac)


Moreginger - these are just warnings(for the time being) they should still function properly.

Ah thanks. So perhaps there was a further problem downstream in the log. I've requested more information.

I'll file a bug about the warning in xbmc trac.

moreginger Wrote:I'll file a bug about the warning in xbmc trac.

http://trac.xbmc.org/ticket/12679

LOL. we put the warning there for a reason. hint; the reason is NOT having a trac ticket opened on our ass.

spiff Wrote:LOL. we put the warning there for a reason. hint; the reason is NOT having a trac ticket opened on our ass.

It now says ERROR and not WARNING so i think that's why the ticket was made (can't acces trac @work because of stupid content control)

spiff Wrote:LOL. we put the warning there for a reason. hint; the reason is NOT having a trac ticket opened on our ass.

Apologies, I opened the trac issue primarily because I don't understand how I am supposed to fix this deprecation warning in Lib/multithreading/process.py and Lib/tempfile.py.

On the trac issue you point out that the plugin needs to switch to xbmc.python 2.0 for Eden. I didn't know this, but from reading [1] I get the impression that this will simply force the deprecation error to be rigorously enforced.

Perhaps setting xbmc.python 2.0 will cause different (fixed) versions of the libraries to be used as well, but that would surprise me?

[1] http://wiki.xbmc.org/index.php?title=Eden_API_changes

if you set python 2.0, we will not override os.getcwd at all. the whole point of the warning is to inform peeps who port dharma code.

spiff Wrote:if you set python 2.0, we will not override os.getcwd at all. the whole point of the warning is to inform peeps who port dharma code.

From this I infer that it is currently overridden to "do the thing that you should have done in the first place"?

But from http://wiki.xbmc.org/index.php?title=Eden_API_changes

Quote:Certain deprecated functions like os.getcwd() will produce a warning in backwards-compatibility mode, whereas they will fail outright otherwise. Add-ons with this enabled will not be accepted into the Eden repo, they should instead be updated.

If this is true, then how is setting python 2.0 not going to cause the addon to fail outright when it tries to use the library modules? Well I can try it tonight I suppose

Thanks for your help.