[KenV99]

I wish I had noticed this thread like 6h ago.
My workaround (which is not pretty) was just inserting any outside modules paths into sys.path for any scripts that are not called via the extension points defined in addon.xml.

I guess one fix would be to create additional extension points in addon.xml for any files that are called by runscript (i.e. from settings.xml or keyboard.xml) that could load the other dependencies when called? That would at least prevent regression back to the load everything mentality.

Edit:
By load, I meant insert into the path any other dependencies already defined in that module...

[takoi]

I wish I had noticed this thread like 6h ago.
My workaround (which is not pretty) was just inserting any outside modules paths into sys.path for any scripts that are not called via the extension points defined in addon.xml.

I guess one fix would be to create additional extension points in addon.xml for any files that are called by runscript (i.e. from settings.xml or keyboard.xml) that could load the other dependencies when called? That would at least prevent regression back to the load everything mentality.

Edit:
By load, I meant insert into the path any other dependencies already defined in that module...

Not entirely sure if this is what you meant but loading dependencies when called with path isn't possible as a fallback. That is the main problem here: if you pass path to runscipt, there is simply no info on which addon this file belongs. It just a random file. It could be anywhere. I'm thinking just loading every module installed as the fallback when calling with path is the most sane approach at this point. (would at least give people time to update, even though to the best of my knowledge very few addons rely on this behavior). Would that help, or have you already update your addon?

To clear up one other thing: There should only be one script extension point. Otherwise it's ambiguous which one to call. Long term solution to all of these problems I think is to have everything use RunScript(my.id). If you need to support more than one 'action' or functionality, use args: RunScript(my.id, myargs). Then the main python script reads args and take the relevant action. settings.xml can use RunScript($ID, myargs). After that I don't think there will be any need call scripts that belong to an addon by path. (You can ofc. hack sys.path at your own risk if needed)

[ironic_monkey]

and a FYI. this ^^ (dependency tracking for random scripts) is why i added the script.library extension point in the first place, but nobody seem to use them (supposed to be hidden in the gui but somebody thought it was a good idea to show them there lately).

[takoi]

and a FYI. this ^^ (dependency tracking for random scripts) is why i added the script.library extension point in the first place, but nobody seem to use them (supposed to be hidden in the gui but somebody thought it was a good idea to show them there lately).

Sure they do. More or less everything skin related use it. If we're talking about the same thing here, they are only shown in addon brower afaik. not in programs menu.

[ironic_monkey]

yes, they show in the addon browser. they used to be completely hidden for easy bundling with some other "main" addon type (e.g. a pluginsource) without confusion. ignore that bit wasnt meant to be the focus point

[KenV99]

Not entirely sure if this is what you meant but loading dependencies when called with path isn't possible as a fallback. That is the main problem here: if you pass path to runscipt, there is simply no info on which addon this file belongs. It just a random file. It could be anywhere. I'm thinking just loading every module installed as the fallback when calling with path is the most sane approach at this point. (would at least give people time to update, even though to the best of my knowledge very few addons rely on this behavior). Would that help, or have you already update your addon?

To clear up one other thing: There should only be one script extension point. Otherwise it's ambiguous which one to call. Long term solution to all of these problems I think is to have everything use RunScript(my.id). If you need to support more than one 'action' or functionality, use args: RunScript(my.id, myargs). Then the main python script reads args and take the relevant action. settings.xml can use RunScript($ID, myargs). After that I don't think there will be any need call scripts that belong to an addon by path. (You can ofc. hack sys.path at your own risk if needed)

I haven't issued a pull request yet. I overall like the idea of using my.id, however, I don't know if there is anyone out there running scripts from places like keyboard.xml where the script that is being called isn't part of an addon. I can envision that some users might have attached a script to a hotkey that does something unrelated to kodi, like turns off the lights and the script is just sitting in some random directory. Can it be that runscript accepts either syntax?

[takoi]

I haven't issued a pull request yet. I overall like the idea of using my.id, however, I don't know if there is anyone out there running scripts from places like keyboard.xml where the script that is being called isn't part of an addon. I can envision that some users might have attached a script to a hotkey that does something unrelated to kodi, like turns off the lights and the script is just sitting in some random directory. Can it be that runscript accepts either syntax?

Should absolutely not be removed imo if I gave a different impression. It's great for hackability. I'm talking about dependencies here. Such scripts shouldn't need access to internal module addons (you cant even control what installed normally) so it's not a issue removing that particular feature.

[Lunatixz]

@takoi, i'm rereading all of the posts since there is new activity... I have to apologize for a statement I made earlier, it wasn't placed in proper context... my post was poorly written and wasn't meant to be directed to you... but xbmc and the problem at hand... because of my quick tapatalk skills it came off harsh and directed towards you. Sorry if it offended you, my bad...