Is there a way to access python code from third party kodi/xbmc plugins in your plugin? - xbmc

I have experience with python, but I just got started learning how to develop addons for Kodi. Having a bit of trouble understanding the docs.
Is it possible to import or otherwise access python code from another plugin or script?
For example if my addon was: script.hello.world and i wanted to use some_method from plugin.video.someplugin.
addon.xml imports the plugin i wish to access:
<requires>
<import addon="xbmc.python" version="2.14.0"/>
<import addon="plugin.video.plexbmc" version="3.4.5" optional="true"/>
</requires>
I was fairly sure this would not work, and i was correct:
from plugin.video.someplugin.default import some_method
The only thing in the docs that looked like it might work was this:
spi = xbmcaddon.Addon ('plugin.video.someplugin')
I can access the xbmc's built in methods of spi, but no way to get to the actual python objects.

Got it! Simply add the desired directory to the system's python path:
spi = xbmcaddon.Addon ('plugin.video.someplugin')
path = spi.getAddonInfo('path')
sys.path.append (xbmc.translatePath( os.path.join( path) ))
from default import some_method
some_method()

Related

Save a downloaded file to storage folder on android

I've made an app that sends a file from my pc to my phone but I can't figure out how to save it to Internal storage or to a folder I can access. Can someone please help?
Looks like you need to use the FileSystem API. According to the documentation here, you need to first install it:
expo install expo-file-system
And of course, import it where needed:
import * as FileSystem from 'expo-file-system';
After which you should be able to use the method FileSystem.writeAsStringAsync and save the file to the FileSystem.documentDirectory:
FileSystem.writeAsStringAsync(
FileSystem.documentDirectory + 'filename.ext',
"some file contents or variable");
Look around the documentation about FileSystem - there are many useful methods and some examples that should help you.

Webpack require/import image without extension

I want to import/require an image that doesn't have an extension. Is this possible? For example currently I can import jsx files without writing the extension. What if I want to do the same for image files or other type of files that lack file extension?
E.g. require('./avatar.png') will work. What I want to work is require('./avatar')
I'd strongly advise against doing this, as writing the extension makes it more explict exactly what's being imported.
For example, if you had avatar.js, avatar.png and avatar.css in the same folder, is it easy to tell what import ... from './avatar' will give you? Having similarly-named files with different extensions is not an uncommon convention.
But, either way, you can add the extensions you want to resolve.extensions in the webpack config, like so. Try to be responsible with it.
module.exports = {
//...
resolve: {
extensions: ['.js', '.jsx', '.png', '.jpg', /* ... */]
}
}

Python enthought apptools with merging namespace

I am currently using python 2.7 with enthought from pythonxy package.
In my software, I need to use my own user_manager and other permissions tool. So I need to add external sources into apptools.permissions.
In apptools documentation, it said I need to develop another egg with namespace, apptools.permissions.external.
Therefore, I have developed a folder with three level:
apptools,
apptools.permissions,
apptools.permissions.external.
and setup.py.
In setup.py, I wrote:
# 3
from setuptools import setup, find_packages
setup(
name = "apptools.permissions.external",
author = "Airbus",
version = '0.1' ,
include_package_data = True, package_data={'': ['*.*']},
packages = find_packages(),#exclude=["*.tests", "*.tests.*", "tests.*", "tests"]),
test_suite = 'nose.collector',
entry_points = """
[envisage.plugins]
apptools.permissions.external = apptools.permissions.external.permissions_plugin:ExternalPermissionsPlugin
""",
#install_requires = ['Aerocity==1.01'],
zip_safe=True,
namespace_packages = ['apptools',
'apptools.permissions',
'apptools.permissions.external',
],
)
However, after I did python setup.py develop. I went to python and try to import apptools.permissions.external.
Python told me:
>>> import apptools.permissions.external
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named external
So it somehow cannot find this external egg. However, if I quickly changed the name of apptools to like apptools_test and related in folders and setup.py. I actually can import apptools_test.permissions.external.
So I think there is some problems when I merge namespace apptools.permissions.external to apptools. Python somehow gets confused.
Could someone help me with this case?
apptools.permissions was architected a long time ago when it was enthought.permissions and enthought was a namespace package. We have long since stopped doing that and refactored most of ETS into separate packages (sadly, apptools is still something of a grab-bag). When we did that, it seems that no one noticed that it was (ab)using the namespace package like that. Sorry about that. We, uh, don't use it much ourselves. Take that for whatever cold comfort it brings you. :-)
The only places it does this kind of indirection is in _*_default() methods, so you should be able to just assign your own instances for these traits. I'm not really sure why the namespace extension mechanism was attempted at all.

using phpunit without composer

I'm trying to instal PHPunit on an old system,
I'm dealing with several phar issues,
from now i've managed to have PHPunit running, to have my autoload working, also the pPHPunit, but now, it is trying to call composer.
i Had to add an extention "PHPUnit/Extensions/Story", it's also working, but now, i've got to manage composer...
I tried to add the phar, to extract the phar , ... but nothing seems to work (if "Composer\Autoload\ClassLoader.php" work, then I've got an "Instantiator\Instantiator.php" missing...)
So, is it possible to have PHPunit running without composer?
I juste solved the problem :
despite I called "spl_autoload_register" for my own framework afeter including PHPunit and Composer"s ones, mine was sometimes called before, so I juste added a whitelisting in my autoloader (see $tabLibCommunPrefixes):
function phpunit_bootstrap_autoload($class_name) {
$prefixe = substr($class_name, 0, strpos($class_name, '_'));
$tabLibCommunPrefixes = array('Smarty', 'Zend', 'Bvb', 'Composer', 'domxml-php4-compat', 'FirePhp', 'Mobile', 'Nusoap', 'Pear', 'phing', 'PhpMailer', 'phpThumb', 'Sitra', 'Smarty3', 'smarty', 'test', 'upload', );
if (in_array($prefixe, $tabLibCommunPrefixes)) {
require_once str_replace('_', '/', $class_name) . '.php';
return true;
}
return false;
}
One can simply use composer to handle only PHPunit and it's dependencies.
So the easiest way is to simply use composer. There is nothing wrong at using composer for just a small part of your dependencies. In fact, for some (small) projects I even use it for no dependency at all (only to handle the autoloading).
You can use it in the subdirectory test, or more conventionally at the root of the project.

How can I create a JSON webservice to store and retrieve data from a simple properties file?

How can I create a Java or Javascript JSON webservice to retrieve data from a simple properties file? My intention is to uses this as a global property storage for a Jenkins instance that runs many Unit tests. The master property file also needs to be capable of being manually edited and stored in source control.
I am just wondering what method people would recommend that would be the easiest for a junior level programmer like me. I need read capability at miniumum but, and if its not too hard, write capability also. Therefore, that means it is not required to be REST.
If something like this already exists in Java or Groovy, a link to that resource would be appreciated. I am a SoapUI expert but I am unsure if a mock service could do this sort of thing.
I found something like this in Ruby but I could not get it to work as I am not a Ruby programmer at all.
There are a multitude of Java REST frameworks, but I'm most familiar with Jersey so here's a Groovy script that gives a simple read capability to a properties file.
#Grapes([
#Grab(group='org.glassfish.jersey.containers', module='jersey-container-grizzly2-http', version='2.0'),
#Grab(group='org.glassfish.jersey.core', module='jersey-server', version='2.0'),
#Grab(group='org.glassfish.jersey.media', module='jersey-media-json-jackson', version='2.0')
])
import org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpServerFactory
import org.glassfish.jersey.jackson.JacksonFeature
import javax.ws.rs.GET
import javax.ws.rs.Path
import javax.ws.rs.Produces
#Path("properties")
class PropertiesResource {
#GET
#Produces("application/json")
Properties get() {
new File("test.properties").withReader { Reader reader ->
Properties p = new Properties()
p.load(reader)
return p
}
}
}
def rc = new org.glassfish.jersey.server.ResourceConfig(PropertiesResource, JacksonFeature);
GrizzlyHttpServerFactory.createHttpServer('http://localhost:8080/'.toURI(), rc).start()
System.console().readLine("Press any key to exit...")
Unfortunately, since Jersey uses the 3.1 version of the asm library, there are conflicts with Groovy's 4.0 version of asm unless you run the script using the groovy-all embeddable jar (it won't work by just calling groovy on the command-line and passing the script). I also had to supply an Apache Ivy dependency. (Hopefully the Groovy team will resolve these in the next release--the asm one in particular has caused me grief in the past.) So you can call it like this (supply the full paths to the classpath jars):
java -cp ivy-2.2.0.jar:groovy-all-2.1.6.jar groovy.lang.GroovyShell restProperties.groovy
All you have to do is create a properties file named test.properties, then copy the above script into a file named restProperties.groovy, then run via the above command line. Then you can run the following in Unix to try it out.
curl http://localhost:8080/properties
And it will return a JSON map of your properties file.