Kodi Community Forum

Full Version: import package?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
So as you may know or soon to figure out I am self taught anything to do with python as many of you are. Going on that I have a working add-on in python 2 upon testing in python 3 it fails miserably.
This brings up basic question that I cant seem to find by just googling as before, it may be I am not asking them correctly, so I come here for help if you may.

biggest issue I read that when importing a sub directory it has to be a absolute path that py3 no longer support relative paths...

So where I have
xml:

My add-on/
My add-on/lib
my add-on/lib/mysqlpackage
my add-on/lib/mysqlpackage/its scripts and subfolders

before I could import a .py from my lib with
python:
import lib.database

once done I could import other items the lib folder by simply calling them. Now with py3 I have to lib. in front of every import. And that is fine but my issues comes in when I try to import the sqlpackage

before I could simply
python:
import mysqlpackage
from the database.py

and I am assuming it imported the complete code as it worked as expected. where as now I am not sure how I should import the package as a whole.
I'm dense, and I don't quite get this.  Say I have some requires in my addon like:
    <import addon="plugin.video.youtube"/>
    <import addon="script.module.kodi-six"/>
    <import addon="script.module.routing"/>

How would I use the fully qualified naming convention to import these into my addon/script for python 3 compatability?

Thanks!
if there other addons be sure they are in the required part of the addon xml.... if it is a package you have in your addon be sure to use assuming you would have dropped the package into a library folder wyou would simple put lib.the name of the package.the name of entry point in the package.

at least that is my understanding.... and I did have it working I haven't check anymore lately.
Importing for external modules/packages works the same way as in Python 2. Absolute import with fully-qualified or relative (dotted) module names is needed if you are importing another (your) module from within your own package. This is actually a very useful change that prevents subtle bugs because of name clash when some other package include a module with the same name as your own module.