To address some of the issues with the Script Module system, we are currently looking at developing a module to support external scripts. We would appreciate any comments.
Specifically we are looking to address the following:
[ol]
[li]Cannot use own editor/tools to work with Script Modules[/li]
[li]Script Module system does not do ‘module scope’ correctly (viewtopic.php?f=72&t=8684)[/li]
[li]Script Modules share a single lock (two developers cannot edit different script modules at the same time)[/li]
[li]Even if Script Modules had individual locks, developers need to be able to work independently (using a VCS to handle merging)[/li][/ol]
The idea is to work with real files added to the Python sys.path. In order for distribution to work correctly, the files will need to be made available in known locations:
[ul]
[li]- Developer’s working copy, $DEV (e.g. $HOME/foo_project)[/li]
[li]- Distributed copy, $DIST (e.g. $TEMP/ignition_files/foo_project)[/li][/ul]
[ol]
[li]Add a function to the designer interface that serialises all files from $DEV into a resource.[/li]
[li]Gateway/clients unpack this resource into $DIST.[/li]
[li]Gateway and normal clients add $DIST to the Python sys.path.[/li]
[li]To enable concurrent editing, designers and staging clients add $DEV to the Python sys.path.[/li][/ol]
We welcome any comments on this scheme. Would anyone else use such a system if we made it available?
First of all, we think this is a great idea. I do think that people will use it if it is put together in a clean way and is compatible with any VCS.
As far as architecture goes, there are about a zillion ways to do it. Your way may work well, but I’m not sure that sys.path will work within Ignition. It may, I’m just not sure. Here’s the architecture we came up with after discussing it for a few minutes.
I think it’s important that the scripts get distributed to client/designer machines automatically. I would use Ignition’s built-in methods of distributing resources to the Designer and the Client, as opposed to you own external script syncing. This will ensure that each launched Client has a copy of the script.
Folder on the Gateway full of scripts. This folder is under version control.
Module on Gateway that monitors this folder. Location of folder is a setting configurable in the Gateway config section.
When files change, module reads files, stuffs them into a ProjectResource, and inserts them into Project(s).
Client/Designer part of the module unpacks files from this project resource. and either:
a) Puts them directly into the Jython system via the ScriptManager -OR-
b) Writes them to a temp file and updates sys.path
Developer checks out folder on local machine (anywhere). Developer modifies scripts and commits changes.
Gateway has RPC function do do an exec() that pulls from VCS into the folder.
Designer has menu item to call RPC function() in 6. So…
Developer hits menu item in 7. after committing changes in 5. This pulls on the Gateway. That triggers the project(s) to be modified, causing the scripts to flow down into clients/designers.
Hopefully that made some sense. Again, this is just a suggestion, there are many ways to accomplish something like this. Good luck!
A fair amount of testing has shown that sys.path does work well within Ignition, and also avoids some of the issues with the Script Module system.
We also came to the conclusion that it was necessary to distribute scripts using the ProjectResource system. We couldn’t think of any sane external synchronisation scheme that would be reliable enough.
We were originally planning to make the gateway use the repository directly. However, one of our clients has a restricted network, so we have to use our own local gateway for development/testing. To deploy, the project file is exported, transferred to the client’s restricted network and then imported on their gateway. This gateway->gateway distribution means that gateways also need to unpack the code from the ProjectResource and use the unpacked version.
The main issue at the moment is the ability for developers to work independently and test in Ignition, without having to push their changes to everyone. I still need to convince my boss that this can be achieved in a sensible fashion.
You could distribute the scripts using the project resource system, and have the client extract them out to a directory on the local machine that is then used by sys.path. This way you get to use sys.path and the project resource style of distribution.
You could also use the staging/publish system this way for testing changes.
It appears there may be an issue with this approach.
Python code stored on the client as real files can be viewed easily by anyone with access to that machine. More disturbingly, they can also be modified. Obviously the changes only take effect for Ignition clients running on that machine, but since Ignition does not provide any gateway/server-side validation this would allow arbitrary tag changes and SQL queries.
The use of ScriptManager.addScriptModule() fixes this problem, at the expensive of still having to deal with the Script Module system.
Does anyone have any suggestions how this problem can be overcome without having to fall back to the Script Module system?
Yes it’s mainly the scoping issue. It seems unlikely that this will be fixed in the Script Module system due to backwards compatibility concerns so it would have been nice to find a workaround. I don’t see that I have much choice at the moment though.
We’ll have to look into the script module’s scoping. Maybe we can add another call on ScriptModule that adds modules in a different way that avoids the scoping issue. I’ve made a ticket for it.
[quote=“adamaustin”]It would be great if the windows could be serialized (such as when you export the file) and put under VCS also.[/quote] Either I’m not understanding, or this is a complete non-sequitur.
All we’re talking about re: scripting is to separate out each individual module script and have them independently locked so that different sections of script can be simultaneously edited by multiple designers.
