Hi @roberto​ 

How did you install the Python module? Did you use pip?

The cx_Oracle module is a relatively simple one so you only should have a .pyd file that is named cx_Oracle.cp<pythonVersion>-win_amd<bitVersion>.pyd as well two directories in C:\\Users\\<user>\\Documents\\FME\\Plugins\\Python\\python<version>

What do you see when you navigate to those folders using File Explorer?

Hi @debbiatsafe​ 

thanks for the answer. It is the first time I face such problems with libs.

On the other hand, it is also the first time I install FME under C:\\program files in 64 bit version using 3.x python version.

Maybe I found the reason why the process ends with the python27.dll conflict. Regardless of the Preferred Python Interpreter (FME Python 3.7+, 3.6+, etc.) I select in FME Options (saving the file before to run it), opening it with notepad, I always find #!  PYTHON_COMPATIBILITY="27". Changing manually the value to "37", the translation ends successfully. Creating a file from scratch, changing the interpreter before to insert the PythonCaller, it works and the python compatibility is set properly to "37". I will perform some other tests but it seems that the most troubling problem is solved. The lib not found problem is still there. I've installed cx_Oracle with pip following the standard procedure and the "C:\\Users\\myself\\Documents\\FME\\Plugins\\Python\\python37" folder includes the lib (cx_Oracle.cp37-win_amd64.pyd) and two sub-folders. As you wrote. Do you think I need to install libraries somewhere else? Or, maybe, I forgot to set some "path" variables?

Regards

Roberto

Hi @roberto​ 

The Preferred Python Interpreter setting sets the default Python Compatibility value for new workspaces and does not affect new workspaces. In existing workspaces, you need to change the Python Compatibility parameter (in Navigator > Workspace Parameters > Scripting). This performs the same action as editing the line #!  PYTHON_COMPATIBILITY="27" in Notepad.

You should not need to modify the PATH environment variable. By default, FME searches the FME\Plugins\Python directory is a default path where FME searches for Python modules. 

What are the results when you run the following in a PythonCaller or Python startup script?

import sys
for path in sys.path:
    print(path)

One of the paths in the output should be C:\Users\<user>\Documents\FME\Plugins\Python\python37

Hi @debbiatsafe​ ,

you hit the point.

Including that snippet and looking to the results, I discovered an interesting configuration.

After the latest Windows update (done remotely by our sysadm), OneDrive "overrides" the standard user path (C:\\Users\\myself\\Documents).

C:\\Users\\myself\\OneDrive - Company\\Documents\\FME\\Plugins\\Python

C:\\Users\\myself\\OneDrive - Company\\Documents\\FME\\Plugins\\Python\\python37

C:\\Program Files\\FME2020\\python

C:\\Program Files\\FME2020\\python\\python37

C:\\Program Files\\FME2020\\fmepython37\\python37.zip

C:\\Program Files\\FME2020\\fmepython37\\DLLs

C:\\Program Files\\FME2020\\fmepython37\\lib

C:\\Program Files\\FME2020

C:\\Users\\myself\\AppData\\Roaming\\Python\\Python37\\site-packages

C:\\Program Files\\FME2020\\fmepython37

C:\\Program Files\\FME2020\\fmeobjects\\python37

C:\\Program Files\\FME2020\\plugins

I've copied under onedrive path the cx_Oracle (deleting from C:\\Program Files\\FME2020\\python\\python37 folder) and the script works fine.

Thanks!!

Regards

Roberto

I had a very similar problem last week, and this always happens with Applications that use the Windows "Documents" Folder as the default Folder for storing Application data.

The trouble is this is one of the most redirected and often restricted folders in Windows Enterprise. Applications that point to this will get redirected and suffer from all sorts of weird and wonderful behaviour ranging from lag in read/writing from what very often is a Network Folder Share on a WAN or just plain runtime errors.

The difficulty I found was that whilst the Python plugin seemed to get installed to my actual local C:\\ Documents Folder by PIP (following the Safe Guideline on how to install plugins), when FME tried to refer to it inside a Workflow, Windows will redirect FME to look in the redirected Network Folder Share of "Documents" where it doesn't exist and throw a runtime error.

A note for Safe and other Application Vendors (I'm looking at you too ESRI!): Please don't do this. Use %APPDATA% as the much safer place for Application data files that only need to be localised to the PC and User. Eg. "C:\\Users\\UserName\\AppData\\Roaming\\FME\\Plugins\\".

The learning for me in this thread though was the Environment Variable override possibility. I googled that but didn't seem to show up at least how I searched for it.

My workaround was instead to install the Python plugin directly to my Project Folder and that worked fine, so kudos to Safe for having that as a default searched location as well. Python on Windows reincarnates to whole "DLL hell" issues that used to exist in Windows! I'm only a Python illiterate, but I still don't know WHY you don't have the option to statically link your script to a static path of a Python Plugin/Library in the "Import" statement unlike say in most other languages......doesn't really seem that Pythonic!

Hi @bwn​ ,

running the code snippet as suggested by @debbiatsafe​ , noticed that "C:\\Users\\myuser\\AppData\\Roaming\\Python\\Python37\\site-packages" is one of the path that FME considers. I moved there my python libraries and it seems to work. Unfortunately one of the lib (numpy) already exists in standard FME installation with too old version for Pandas. In a separate post I will ask about the possibility to update the default one with a newer one. About the usage of the path under appdata, do you think it is a possible solution to avoid "documents" and "OneDrive" problems?

Roberto

I don't think it is that FME "considers" the Path, but rather sys.path is the default path that Python itself searches. What sys.path returns by default is the Windows PATH Environment Variable setting, among other folders such as PYTHONPATH.

If C:\\Users\\myuser\\AppData\\Roaming\\Python\\Python37\\site-packages is returned, then this means that an application has probably added that Path to the PATH Windows Environment Variable, I would guess it was added when Python 3.7 was separately installed because it is sensible enough to NOT use the Documents Folder! So FME is considering that Path, simply because the installation of Python 3.7 added that path to the Windows PATH Environment variable.

Every other application we've encountered at the Enterprise level that either by default used APPDATA like this, or was able to be reconfigured to use APPDATA (such as in an Application Option or Windows Registry Key setting etc.) removed the issue of Documents being a redirected Folder.

@bwn​ ,

you are right. In fact that folder was created by Python. I totally agree with your suggestion to Safe to follow such best practices and avoid as much as possible other path.

Hi @bwn​  and @roberto​ 

Thank you for your feedback. I have shared it with our development team and they suggested using the Shared FME Folders (found under Options > Default Paths > Shared FME Folders) to add a custom location such as %appdata% or another custom path. Note that you do need to manually create Plugins/Python subdirectories within the Share FME Folder path.

Would this help address the issue you are seeing with path redirects?