Fusion
Accepted solution
I'm not sure why that did not work. The Python/lib folder is set to the system path on Fusion startup, so any packages located there should be found when imported from any script.
However, I definitely would not recomend installing packages into this Python/lib folder for your scripts. One reason is that the specific webdepoly path will be abandoned every time the application is updated (every few weeks or so). You would have to continuously apply your modifications to those locations.
The other reason is that the Python environment in Fusion is a shared environment for all loaded scripts and addins. Different scripts could be dependent on different versions of libraries. Plus there is no (as of yet) setup/install phase for scripts. A 'copy to deploy' model is desired. For these reasons, the recomendation would be to include all of your dependent libraries in your script folder and use relative imports ('from .packages import collada' and copy (or virtual environment install) the libraries into 'YourScript/packages'). Most packages include their own dependencies and use relative imports, but some (such as collada) assume a shared install of numpy exists. In that case, you would either need to change the collada code to do package (your script's package) relative imports of numpy (or any other external dependencies not in our distro), or use an absolute import.
Now using script relative libraries gives this isolation, but it can increase redundancy. This normally wouldn't be a problem with publicly shared or published scripts. But if you use a large library (say numpy) in a lot of your own local scripts, this would grow to be a problem. In that case, you could create a shared library location and do an absolute import after modifying the sys.path list to include your shared library folder. I would put this shared library folder out in the user API folder so it survives across updates (or any location convenient to you, but using a location relative to your scripts would make it more portable if you ever shared your scripts).
Kris
Kris Kaplan
Fusion currently uses version 3.3.5 of Python located in the Fusion install (webdeploy) folder. Just as you can install multiple separate versions of Python on your machine and packages installed in one are not visible to the other. The same is true for the version of Python used by Fusion. Even if it is the same version as another version of Python on your system, packages installed on one are not visible to the other.
This is all controlled by the standard package resolution rules in Python. Packages are searched for relative to the current running module's __file__ path, then in some standard locations relative to the Python runtime location (e.g. site_packages), and then the paths enumerated by sys.path. So in order to use a package in your Fusion script, it needs to be in one of these locations. As mentioned above, you should avoid trying to add the packages directly to Fusion's Python folder, because this is in the webdepoloy folder that is recreated on every update and all scripts run in this shared environment, so there can be version problems between scripts. Unfortunately, this would normally be the standard way to install packages. So this leaves either relying on the module relative import mechanism (preferred), or modifying sys.path to point to the absolute path where these packages are located.
Unfortunately, the scientific packages (like numpy) make this harder with their extensive use of binary extensions. And because numpy is so large, other packages like scipy normally assume numpy is available in the system path, and does not do a relative import (like other smaller packages tend to do). This makes copying something like scipy into your script's folder and referencing it with a relative import a little more difficult (as it would require editing some of their files to perform relative imports). So the easiest way forward would probably be to have your script append the path to these packages onto sys.path before importing these modules. This has the downside of affecting the module search order for all scripts run in Fusion, so it would be best to revert the sys.path as soon as you are done (and ideally remove these absolute imported modules from sys.modules). To do this, I might use virtualenv to create a virtual environment from a 64bit Python 3.3.5 (from Fusion's install directory or one you setup), and setup the desired packages (scipy, numpy), and add the path to this virtual environment's site-packages folder to sys.path in your script (if not already present). Even better, you could copy the relevant module's from the virtual environment into a folder relative to your script (or common to all of your scripts if referenced by several) and add that folder to sys.path. (Doing this prevents the other modules in the virtual environment's site-packages from being visible in the path.)
Another thing to be aware of is that because Python is running embedded in the Fusion process, and the Fusion process is a 64bit process, the Python version is also a 64bit version. And because the scientific packages use binary extensions, you have to ensure that you get the 64bit versions of these packages (numpy, etc...) or they will not import in a script run in Fusion.
Kris
Kris Kaplan
