Hmm possibly because you are using the Data Interop version of FME rather than FME itself. There might be some limitations there. I can't really see why that would be a an issue though.

Is the fme Installation (or data interop extension) directory also in the PATH variable? i.e., can you call 'fme' in a terminal?

Hi @James Singleton​ 

What version of Python are you using to call fmeobjects? I have seen the dll error occur when using the incorrect version of fmeobjects for the Python interpreter used (eg. 3.8 fmeobjects with Python 3.7). Likely isn't the issue here but would be good to double check.

Depending on the version of Python used, I agree with @virtualcitymatt​'s suggestion of adding the home directory for Data Interoperability (C:\\Program Files\\ArcGIS\\Data Interoperability for ArcGIS Pro by default) to the PATH environment variable. A more temporary solution would be to use the os module's chdir function to change the current working directory to Data Interop's home directory.

However, please note that adding the Data Interop home directory to PATH or changing the current working directory will not work starting in 3.8 due to a change implemented for loading DLL dependencies within Python. If you're using Python 3.8, then please use os.add_dll_directory().

I am seeing the same behaviour trying to use PyCharm to write some unit tests.

Can you expand a little on your last comment there debbie?

Hi @virtualcitymatt​ 

My comment was referring to this change specifically:

> DLL dependencies for extension modules and DLLs loaded with ctypes on Windows are now resolved more securely. Only the system paths, the directory containing the DLL or PYD file, and directories added with add_dll_directory are searched for load-time dependencies. Specifically, PATH and the current working directory are no longer used, and modifications to these will no longer have any effect on normal DLL resolution.

For example, when using fmeobjects with Python 3.8, modifying PATH with sys.path.append() to add the home directory of FME or Data Interoperability does not allow the required DLLs to be resolved. However, using os.add_dll_directory() does work.

I haven't had the chance to test this outside of Python IDLE though so the behaviour may be different in various applications.

I experienced the same problem when running python 3.7 and the script was trying to use a version 3.6 fmeobjects. I have fme desktop installed so it was simply a matter of changing this line sys.path.append(r"C:\\Program Files\\FME\\fmeobjects\\python36") to this line sys.path.append(r"C:\\Program Files\\FME\\fmeobjects\\python37") If you look in C:\\Program Files\\FME\\fmeobjects you will see different folders for different versions of python. I don't have data interoperability for ArcGIS pro installed but I suspect there would be a similar arrangement. Thank you @debbieatsafe for the tip above.

Has there been any definitive answer to this?

I have the same issue of "ImportError: DLL load failed: The specified module could not be found".

I am able to replicate the error change when I misspell fmeobjects deliberately.

I am running FME Workbench 2020.2 not data interop via GIS. And I am trying to run my FME workbench via python using Jupyter Notebooks (python version 3.7.10 directing to sys.path.append(r"C:\\Program Files\\FME_2020.2.2\\fmeobjects\\python37").

Don't think so. I never had the chance to revisit this and fix the issue, sorry. I tried Debbie's solution but that didn't work for me. At the time I suspected it was to do with the path variable still defaulting to the wrong python version as set in the environment variables, but never tested it so that's just speculation.

To make it short, it means that you lacked some "dependencies" for the libraries you wanted to use. This is a common problem when installing python packages, mainly in windows. Before trying to use any kind of library, first it is suggested to look up whether it needs another library in python "family". 

The solution is to provide the python interpreter with the path-to-your-module/library. The simplest solution is to append that python path to your sys.path list. In your notebook, first try:

import sys
 
sys.path.append('my/path/to/module/folder')

This isn't a permanent change in sys.path, because when you log out, your environment is reset, so any variables you may have set are lost.

The better (and more permanent) way to solve this is to set your PYTHONPATH, which provides the interpreter with additional directories look in for python packages/modules.

from BASH type: export PYTHONPATH=/path/to/new/folder:/another/path/...../    #each path must be separated by a colon