I'd like to be able to maintain python scripts as .py files independant from my workspace (Like I do with sql scripts and SQLExecutor). The pythonCaller doens't allow to parse python code from an existing fme attribute.
That would be handy to implement an AttributeFileReader to read from the .py file and a PythonCaller to run the python script from the _file_content attribute.
Advantage: proper version control of the python scripts in GIT
+3... and add a rejected port?
... and better debugging? :)
+5No problem, Here is a very simple non-safe example:
import fmeobjects # Template Class class FeatureCreator(object): def __init__(self): pass def input(self,feature): newFeature = fmeobjects.FMEFeature() with open('C:\\\\temp\\\\test.py','r') as pyf: for line in pyf.readlines(): if not line: break else: exec(line) self.pyoutput(newFeature) def close(self): # close method must be defined # # output features here to create the features # after reader features have been processed passAnd your c:\\temp\\test.py:
newFeature.addCoordinate(0,0,0) print 'new feature at 0,0,0'
+21Just had exactly this request today. A prospect wanting to use FME to call GIT managed python code directly from the PythonCaller. The SQLExecutor has the ability to read SQL from an attribute so the same capability for the PythonCaller would be a starting position for this that would add some value.
To add to this proposed idea: support Python code that is managed by a git repository AND that runs within virtual environments that can’t interfere with any dependencies that FME has.
I wouldn't support the idea of including code in attributes, just a reference to the directory/file with the code. The workspace features could be stored in a temporary dataset rather than directly ported via the FME python library.
Ideally the log files of the FME job would also include all log output from the script.
+15+15+15Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
