Python module not importing

[esm7b]

I'm having trouble getting the numpy module to work with a python script I've been working on for Fusion 360.  I looked around the forum and I didn't see any other posts with this particular problem.  I even tried running a script that did nothing but try to import the module with no luck.  I've gone so far as to completely uninstall python from my computer except for what comes in Fusion 360.  I ran pip to install numpy into that python installation and then copied that numpy folder into my script folder.

I've setup my folder structure exactly as is shown in the help documentation linked below

http://help.autodesk.com/view/fusion360/ENU/?guid=GUID-743C88FB-CA3F-44B0-B0B9-FCC378D0D782#Addition...

Command:

from .Modules import numpy as np

Error Message:

>>> Traceback (most recent call last):
File "C:/Users/Eric/AppData/Roaming/Autodesk/Autodesk Fusion 360/API/Scripts/Test\Modules\__init__.py", line 126, in <module>
from numpy.__config__ import show as show_config
ImportError: No module named 'numpy'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "C:/Users/Eric/AppData/Roaming/Autodesk/Autodesk Fusion 360/API/Scripts/Test/Test.py", line 1, in <module>
from .Modules import numpy as np
File "C:/Users/Eric/AppData/Roaming/Autodesk/Autodesk Fusion 360/API/Scripts/Test\Modules\__init__.py", line 131, in <module>
raise ImportError(msg)
ImportError: Error importing numpy: you should not try to import numpy from
its source directory; please exit the numpy source tree, and relaunch
your python interpreter from there.

>>>

I don't understand why I'm getting this error since the script is not located in the numpy directory.

[Anonymous]

You're not the first to try (link) - they never followed up so I assume they did not succeed. After my brief investigation the problem is that even if you get it working it won't be re-distributable as numpy is largely a C library that gets compiled for your machine on install. The numpy source has some interesting checks in it to detect if it is running from the installer, or running as a lib, I suspect this is the code path you are seeing (numpy cant find its compiled c code or maybe it's something as simple as a flag / env var is not set). Take a look at the numpy source and work from there.

Good luck, if you figure it out be sure to post how you did it so others can too!

[esm7b]

I was able to fix my problem.  I took the installed numpy folder and moved it to one of the folders in my 'sys.path' list and changed the call from "from .Modules import numpy as np" to just "import numpy as np" and now everything works.  I thought that I had tried installing it in the "..\Autodesk\webdeploy\production\<bunch of numbers>\Python\lib\site-packages" folder with no luck, but when I moved it back in there it ran without any problems.  It doesn't explain the error I was getting when I was trying to import it from the "Modules" folder, but it works now so I'm not complaining.

[balunist]

I am not able to include the package svgwrite with my script plugin.  The package, which is python only and no native code, is contain in the subdirectory svgwrite and includes a __init__.py file.  I've included this package directory in the save directory as my script.  Executing my python module outside Fusion only requires me to include "import svgwrite" and all works.    

I've tried the following:

- Creating a directory Modules and moving the package under Modules as suggested.  This did not work. 

- Located the /Users/xxx/Library/Application Support/Autodesk/webdeploy/production/<bunch of numbers>/Api/Python/packages and copying package here and this didn't work either.   

Creating a plugin without a way to create or use packages is crazy.   Please help!

Thanks in advance!

Bill

[KrisKaplan]

For normal, self contained dependent modules, you would normally only need to copy the dependent modules or packages into a path relative to your script (such as a 'Modules' subfolder), and import with a relative import statement.  For example:

from .Modules import submodule

But some packages make assumptions that they or their dependencies are located in the system path.  In that case, if you attempt to import the module or package, it will import dependencies or it's own modules with absolute imports (instead of relative imports), and that will fail if the parent folder of the module/package is is not in the system path.

In this case, you have two options.  The first is to edit the module/package code so that it uses relative imports on its sub/dependent module imports.  In some cases this is relatively easy.  But in many cases it is non trivial, and in cases of compiled modules it may be impossible without rebuilding it.  The second option is to modify the system path to include your 'Modules' subfolder before importing.

If possible, modifying the module/package to use relative imports would be preferable.  Modifying the system path is simpler, but it can affect the module resolution behavior of other addins or scripts (because they are all sharing the same runtime).  If multiple scripts/addins import a module/package with the same name using an absolute import with a modified system path, they will collide and cause failures for one of them (if they are not the same module/package or the same version).  So if you do modify the system path, do so only around the import (or around any calls that may result in an import that expects it if there are inlined imports).  Make sure to revert your changes to the system path before returning control to the runtime.  For example, I was able to import svgwrite by copying it and the pyparsing.py module into a 'Modules' subfolder in a script and importing it with the following:

modules = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'Modules')
sys.path.insert(0, modules)
from .Modules import svgwrite
popped = sys.path.pop(0)
assert(popped == modules)

Kris

[balunist]

Nicely orchestrated Kris!   That worked and I was also able  to figured out my original problem using relative references which is not worth describing here.   

Thank You for you quick response!   Bill