[IGN-5880]Custom Named code.py files

Ignition
1

Currently with the way that all of the python files are named code.py this can make it a bit of a pain when you are working on a code-heavy project in any external editors.

We do quite a bit of development out of the ignition designer and in vscode, and every file tab being named code can be a bit annoying when you have several open.

It would be a great feature to allow the files to have custom names with an additional key in the resource.json file something like the following:

{
  "scope": "A",
  "version": 1,
  "restricted": false,
  "overridable": true,
  "fileName": "MyPythonFile.py",
  "files": [
    "MyPythonFile.py"
  ],
  "attributes": {
    "lastModification": {
      "actor": "kgamble",
      "timestamp": "2022-04-14T05:54:06Z"
    },
    "lastModificationSignature": "7b2471a290269b3e9d45b4f96b42d490cc7c3170226d20a9ad854b5937bdff5e"
  }
}

In general resource.json files are a bit of a pain, and maybe a simpler way to do this would be for script files to just be stored as true packages and scripts instead of indirecting them by the script name being the folder name, and having one resource.json that monitors a whole list of project scripts, but that’s a request for a different time.

Here is an idea post for the custom named file feature though

Note, by default if no value was found and code.py was the default, this would allow existing projects to continue as currently built, and really just enable this feature for people that would want to take advantage of it.

3 Likes
2

Would an attribute key be overkill?

It seems like the simplest solution would be to store the code at the same filename as the resource itself is. Then an external editor can just ignore the resource.json file.

2 Likes
3

Are you describing it with the current folder names as follows:

.
+--script-python
--------+--MyScript
----------------MyScript.py
----------------resource.json
--------+--MySecondScript
-----------------MySecondScript.py
-----------------resource.json

Or directly as files like:

.
+--script-python
--------MyScript.py
--------MySecondScript.py

In my opinion, option 2 would be fantastic, wince it would allow for you to code references to work in the external editor as well, since it would follow a common python structure. So with an __init__.py file you could treat it all as a package and automated testing as well as external editing would be significantly easier. Currently to do this you require some pretty annoying script imports for it to work.
Like this at the top of your files:

try:
	system.util
	import MyFolder.MySecondScript as MySecondScript
	is_ignition = True
except (NameError, AttributeError, ImportError):
	""" This is not in Ignition, so we need to import code with file paths added """
	sys.path.append(os.path.abspath(os.path.join(os.path.abspath(__file__), os.pardir, os.pardir, os.pardir, os.pardir, 'ignition/script-python')))
	import MyScript.code as MyScript
	import MyFolder.MySecondScript.code as MySecondScript
	is_ignition = False
4

The latter is basically not going to happen, unfortunately. We’d have to “special case” scripts in our project resource system, which pretty much makes it a non-starter. You could always drop your own (regular Python) code into user-lib/pylib on the gateway, and we’ll disseminate it out to clients/designers for you; the downside is that it’s no longer easily editable/viewable inside the designer.

I filed a feature ticket for the former, which wouldn’t solve the pain, but would be an easy change to make for us and at least make things less painful.

1 Like
5

This actually doesn't seem like a terrible idea. One could easily develop the modules there, and then test them externally while not being bound by the constraints of the system. Would files there have access to system.whatever functionality when executed inside Ignition? Also would these files be tracked in a gateway backup or removed during an upgrade?

Also, wouldn't this still have to be jython? Or am I missing something that allows this to be valid python 2.7 instead of jython 2.7?

6

Yes, they'd be executed inside Jython as regular code.

pylib is included in a backup, yes.

Poor choice of words. "regular Python" as in "regular Python package structure" - it will still have to be code able to run in the Jython 2.7 environment.

1 Like
7

Just a comment for backwards compatibility on this, would it theoretically allow the resource name OR code.py?

8

Yes. Since you could have resources stored in the “old” format, what we’d do is increment the version key (and use a different actual file on disk) whenever you open the resource in the designer. Everything else in the system just has to go through the same logic to get the existing resource by name, and that way we can “ratchet” the files to the new configuration seamlessly.

We already do the same trick with named queries, web dev resources, vision windows, etc, in ways that you don’t really need to worry about :slight_smile:

1 Like
9

Second question, as I have thought about this more with my peers. Is there any documentation about how the python libraries restart with the gateway? I know then the last modification time of a python file changes it updates the resource and restarts the gateway scripts, but what about python libraries? Would this require a gateway restart?

10

I’m pretty sure that things are supposed to reload when we detect a change to the pylib directory.

11

IIRC no. If you mod the pylib, within a relative short period of time it will be picked up and sent to open client/designers, I believe the gateway doesn't need restart either, but forgot that specifically.