Environment for embedded python actions

Posted on
Thu Sep 01, 2011 12:42 am
Perry The Cynic offline
Posts: 836
Joined: Apr 07, 2008

Environment for embedded python actions

Can you give us some hints on the environment that embedded python code runs in? I gather its runs in some separate host of its own (sort of like a plugin?). How does this host differ from a plugin host, environment-wise?

I can see that the "indigo" module is pre-imported. Is there any way to control the import path? I'd like my actions to import my support harness (the one I stick into my plugins), but it's not obvious how to do this.

Can embedded Python code leave data behind - such as setting globals or defining functions and classes? Or does the host clean up after each script fragment runs?

What happens (or is supposed to happen) when an embedded Python fragment uses pluginProps? Whose properties are we getting and setting?

(Will the questions ever stop? :-))

Cheers
-- perry

Posted on
Thu Sep 01, 2011 7:18 am
matt (support) offline
Site Admin
User avatar
Posts: 21411
Joined: Jan 27, 2003
Location: Texas

Re: Environment for embedded python actions

Perry The Cynic wrote:
Can you give us some hints on the environment that embedded python code runs in? I gather its runs in some separate host of its own (sort of like a plugin?).

Embedded and external .py files both run inside the same Indigo plugin host (IPH) process that is used by plugins, with a few runtime differences.

First, embedded .py files all use the same IPH process (whereas each plugin AND external .py file get their own IPH process). I did this to avoid the overhead of starting the process, which has to negotiate a connection with the Indigo Server. This means that the embedded scripts need to finish executing in 10 seconds (so the next script can start), or the Indigo Server will kill/restart the embedded IPH. So if your embedded .py script takes longer than that, then use an external file instead so it will get its own IPH process.

Perry The Cynic wrote:
I can see that the "indigo" module is pre-imported. Is there any way to control the import path? I'd like my actions to import my support harness (the one I stick into my plugins), but it's not obvious how to do this.

You should able to (untested) use the standard python technique for appending to the import search path.

Perry The Cynic wrote:
Can embedded Python code leave data behind - such as setting globals or defining functions and classes? Or does the host clean up after each script fragment runs?

Not currently. You might be able to stuff some data that can be found between embedded scripts, but if the Indigo Server has to kill/restart the embedded IPH it will get lost. It also won't work with external .py files at all since they each get their own IPH process.

Perry The Cynic wrote:
What happens (or is supposed to happen) when an embedded Python fragment uses pluginProps? Whose properties are we getting and setting?

.pluginProps for embedded and external .py scripts will always be an empy dict since they aren't running from a real plugin. However, you can still use .globalProps, which is a dictionary of all .pluginProps for that object. So you still have read access to all of the properties. The keys used for .globalProps dict are the plugin IDs specified in the .plists.

Trying to call replacePluginPropsOnServer() will throw an exception.

Other than those runtime differences, the Indigo python scripts should have access to all the APIs/object model as an Indigo plugin.

Image

Page 1 of 1

Who is online

Users browsing this forum: No registered users and 2 guests

cron