So this means, from now on, it would be fully supported to create python libraries in external IDEs, and push updated code to Ignition (with a bit of scripting to account for the renaming from myScript.py to myScript/code.py), and even have them available for editing in the designer (as long as the team agrees on where the canonical version is stored).
Or am I missing something? Like would we have to modify the resources.json file?
What you’re proposing should work. You can play around with this for yourself by just modifying a code.py file on the filesystem (change print "A" to print "B" or something).
I think the code living on the filesystem is just one part of making it possible to edit externally. You still won’t be able to run/compile or access system.* calls without actually running in Ignition.
Yes, for the other part, you need some mock libraries (like GitHub - thecesrom/Ignition: ⚡ A set of packages and modules that allows developers to get code completion for Ignition Scripting API scripting functions in their IDE of choice. ), that allow you to have code completion and even do some unit/integration testing (if the mocks you need get implementations that suit your testing needs).
But there's a difference between a supported solution, and a solution that works most of the time. We already program in a separate IDE, and install the modules as 3rd party libraries by loading them into the pylib directory. But sometimes that doesn't work correctly (f.e. when only updating a deep dependency, it's possible Ignition keeps using the cached version).
However, I tried some different things now. Modifying a script works fine. But when adding a script, I tried without a resource.json, and the script got added as a package without contents.
But when adding a random resource.json file, and restarting the designer, it got rectified again. I could run the correct code before that though.
When you add any resource of any type, you should have to add an appropriate resource.json file as well.
edit: except folders, which is why you saw your resource without a manifest appear as a package.