Skip to main content
Question

FME python interpretter as a different user

  • December 12, 2017
  • 6 replies
  • 35 views
1
Forum|alt.badge.img+1

Hi

Having problems where when we run a workspace pointing at a custom python interpreter (set by system environment variable PYTHONHOME), it uses the specified python interpreter when we run the workspace as my user. When we change to run the workspace as another user (service user running a bat file), then it uses the default python interpreter, not the custom interpreter specified in PYTHONHOME. Any ideas?

I've looked at the recent article here , but it doesn't mention whether there are any specific user settings required. @Mark2AtSafe, any thoughts on this?

Thanks

Mary

6 replies

steveatsafe
Safer
Forum|alt.badge.img+12
  • steveatsafeSafer
  • Safer
  • December 14, 2017

Hi @1spatialmary Are you on FME 2017.1?

I might be way off here... but I'll ask you to try this.

Get rid of PYTHONPATH environment variable.

Then in your FME Workspace - FME Options > Translations > Add a new customer Interpreter.

Finally, back in the Workspace Parameters > Scripting make sure the python compatibility is set correctly. This should work for all users then (but I do have one concern that it may not).

SteveatSafe
steveatsafe
Safer
Forum|alt.badge.img+12
  • steveatsafeSafer
  • Safer
  • December 14, 2017
steveatsafe wrote:

Hi @1spatialmary Are you on FME 2017.1?

I might be way off here... but I'll ask you to try this.

Get rid of PYTHONPATH environment variable.

Then in your FME Workspace - FME Options > Translations > Add a new customer Interpreter.

Finally, back in the Workspace Parameters > Scripting make sure the python compatibility is set correctly. This should work for all users then (but I do have one concern that it may not).

@1spatialmary. So my suspicion was correct. I was way off. I did a little digging and spoke with our lead developer. The above solution won't work where you want this to affect all users...(to allow you to run this via task scheduler) as it will only affect the current user that sets this. This setting is stored in the HKEY_CURRENT_USER registry.

 

 

Although the above would be recommended if you wanted to run the workspace with your current logged on user or set Windows Task Scheduler to user your current logged on user’s credentials it won’t work for other users.

 

SteveatSafe
steveatsafe
Safer
Forum|alt.badge.img+12
  • steveatsafeSafer
  • Safer
  • December 14, 2017

In FME 2017 there are 2 things we set in FME Workbench... the python compatibility and the python interpreter.

The python interpreter setting (in this case a custom python interpreter) is saved in the registry and is for the current logged in user. Meaning it cannot be pushed to the system level where all users would know what python interpreter to use on the system.

The python compatibility can be set in the workspace and thus mobile with the workspace if it were run by a different user or on a different system.

So in this case, one way to get the service account to know what the custom python interpreter is would be to grant a temporarily log in and opening FME Workbench to set the interpreter in FME Options. This would create the necessary registry parameter. However, typically service accounts are headless (a person cannot use the account to log into a system) and thus, would make this step a security no-no (but not impossible).

We are investigating if we could import a .reg file into a service account profile using the Windows Task Scheduler and running a batch file point to the reg file.

SteveatSafe
steveatsafe
Safer
Forum|alt.badge.img+12
  • steveatsafeSafer
  • Safer
  • December 14, 2017
The PYTHONPATH will be picked up by FME, however it doesn't matter as FME will make use of the FME Python interpreter as seen in the service account's registry - which says "use FME's Python Interpreter". As you know, this will present a problem if the python your are attempting to run needs to run via the custom python interpreter.

 

Are you running FME Workbench 2017?

 

 

SteveatSafe
1
Forum|alt.badge.img+1
steveatsafe wrote:

In FME 2017 there are 2 things we set in FME Workbench... the python compatibility and the python interpreter.

The python interpreter setting (in this case a custom python interpreter) is saved in the registry and is for the current logged in user. Meaning it cannot be pushed to the system level where all users would know what python interpreter to use on the system.

The python compatibility can be set in the workspace and thus mobile with the workspace if it were run by a different user or on a different system.

So in this case, one way to get the service account to know what the custom python interpreter is would be to grant a temporarily log in and opening FME Workbench to set the interpreter in FME Options. This would create the necessary registry parameter. However, typically service accounts are headless (a person cannot use the account to log into a system) and thus, would make this step a security no-no (but not impossible).

We are investigating if we could import a .reg file into a service account profile using the Windows Task Scheduler and running a batch file point to the reg file.

Thanks @SteveAtSafe - it's FME 2017.1.0.0 build 17539. I've not got direct access to the environment, so it will take me a little time to arrange it to try these out. I think it's probably best if I raise a support ticket as then I can provide logs etc. and then we can post the findings back here when done

 

steveatsafe
Safer
Forum|alt.badge.img+12

UPDATE: This customers issue turned out being resolved by setting the workspace compatibility parameter to ‘ArcGIS Desktop Python 2.7’ as they didn't really need a custom interpreter.

SteveatSafe

Reply


Helpful Members This Week

Community Stats

31,387
Posts
119,029
Replies
39,012
Members

Latest FME

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.