Scripts: Background Tasks and Attachments

A long, long, time ago, we could load a script at start that contained a set of function desk nations. Then these functions could be called in an inline script. We could also load a script that would just run in the background doing whatever. These were all AppleScripts.

Ok, years later we are about to lose internal AppleScript ability and scripting has transitioned to Python. I have seen the topic Shared Classes and Methods in Python Files (Python Modules) in the Indigo documentation. So, my question is: What, if any, is the future for the Background Tasks and Attachments folders and, is it possible to start a Python script by placing it in the Background tasks folder?

I monkeyed around a little bit and tried a few things. Of course, we can always create a trigger that runs on server startup which loads a Python script. This script will presumably run `forever` (I used a `while True`). But this method requires the startup Trigger to activate it. I don't believe that this script is made available to other processes, but I don't know that for sure. So a server startup Trigger could be a workaround for Background Scripts.

Regarding a standard set of functions for import, if I'm thinking about this right, you could put your script with the functions you want to call into any location that's in the Python path, so a workaround would be to add Indigo's Scripts, Attachments and Background Tasks folders to the Python path. Another option would be to use the `imp` library which should allow the import from any location that Indigo can see, I believe.

Not as elegant as you might want, but I think the combination of the two will achieve what you're looking for. I'm sure you knew all this already, my post is for the group.

+1 on your original suggestion.

...Of course, we can always create a trigger that runs on server startup which loads a Python script. This script will presumably run `forever` (I used a `while True`). But this method requires the startup Trigger to activate it. I don't believe that this script is made available to other processes, but I don't know that for sure. So a server startup Trigger could be a workaround for Background Scripts.

One issue with the Startup Item approach is killing/restarting the script is not straight forward. You have to figure out the pid (logging it will work, but it could be waaaay back there) and then do a command line kill or use the Activity Monitor . By using the Background process approach you can restart by doing Reload Libraries and Attachments.

Regarding a standard set of functions for import, if I'm thinking about this right, you could put your script with the functions you want to call into any location that's in the Python path, so a workaround would be to add Indigo's Scripts, Attachments and Background Tasks folders to the Python path. Another option would be to use the `imp` library which should allow the import from any location that Indigo can see, I believe....

According to the docs,

You may install Python modules/libraries in a special location to make them available to Indigo scripts and plugins, but not to generic Python. This is particularly useful if the module/library includes references to the IOM (since it will only be loaded by processes that know about the indigo module). This location is:
/Library/Application Support/Perceptive Automation/Indigo 7.3/Scripts folder.

So, it sounds like we can, more-or-less, accomplish shared objects as long as we import them.

I am hoping Matt or Jay chimes in here with a discussion of their plans re: Attachments and Background tasks. OTOH, every time they do chime in, my items on the feature wish list fall further back.

FWIW, what I am working on is a monitor script for a Wi-Fi plug that does not broadcast changes in state, it must be polled. To avoid too much chatter, the polling code should only update the plug's state variable for the Indigo Virtual Device (via RESTFul API or IOM) when the state changes. However, the Indigo script that manages the plug synchronously updates the state variable whiner it sends an on/off command. So, if the plug were changed by Indigo, the next poll would see the change and also do an unnecessary update. Not a big issue, but also not real clean. Ideally, the polling script should be interruptible and there Virtual Device script shout signal the polling script whenever a change is made. Thus, all Indigo update would come from the polling script. Yeah, I know there are probably easier ways, but then, what's the challenge.

Who ever said that the easiest way was the best? It's often a lot more fun to do it the hard way.

[matt (support)]

I don't have much to report on this front right now, except to agree with you that we need to think about how we want this to work going forward with Python. The Indigo Server already has the framework to start and stop python processes (on Indigo Server start/stop) and restart them if they crash, so it wouldn't be terribly difficult to expose this in some manner to user scripts.

I monkeyed around a little bit and tried a few things. ... ... so a workaround would be to add Indigo's Scripts, Attachments and Background Tasks folders to the Python path.

So, I actually did try putting python scripts in the Attachments and Background Tasks folders and, as expected, Indigo just ignored them. So, following @DaveL17's suggestion, and in the spirit of Matt's comment... Yes. it would be nice to keep either Background Tasks or Attachments (I don't really see the need for both, but who knows) and have Indigo treat any scripts it finds the same as a Startup trigger but with the added benefit that they can be restarted, for example with the Reload Libraries and Attachments menu item (or similar).