Couldn't init add-on translation when byte code compiled outside NVDA add-ons directory

[LeonarddeR]

In a closed source add-on, I get the following error when I call addonHandler.initTranslation()

ERROR - globalPluginHandler.listPlugins (14:26:49): Error importing global plugin testAddon Traceback (most recent call last): File "globalPluginHandler.pyc", line 22, in listPlugins File "addon\globalPlugins\testAddon__init__.py", line 36, in File "addonHandler.pyc", line 428, in initTranslation File "addonHandler.pyc", line 418, in getCodeAddon AddonError: Code does not belong to an addon package.

Note that the add-on package is compiled outside the NVDA add-on folder structure. I assume that, when byte compiling the add-on file, some static information is added to it which makes addonHandler.getCodeAddon think that the add-on doesn't live in an add-ons folder.

[jcsteh]

You should be aware that (as is normal for the GPL) closed source add-ons are not permitted under the license. All add-ons must be GPL licensed. The license does grant permission to use non-GPL dlls, but only for libraries such as speech synthesisers, etc. So, if closed source add-ons are the only consideration here, this is not something we need to fix.

That said, there are other valid reasons to distribute the byte code without the source code; e.g. reducing binary archive and installation size. (You can satisfy the license by distributing the source separately.) I think this is very low priority, though, since no add-ons are currently doing this.

I'd be surprised if the path really is hard coded into the byte code like this and then returned by inspect, but maybe it is; I haven't checked.

[jcsteh]

P4 because no add-ons are currently doing this and plans to do so seem to be met with a lot of resistance.

[Adriani90]

@leonardder is this somehow improved when using the new scratchpad directory for running code?

[LeonarddeR]

I do no longer care. Closing.