I have a python toolbox that is performing various operations on a layout. Reconfigure text elements, pan the map frame, export to PDF being the core functionality. Editing data is not involved.
The tool runs fine initially, but after trying a second run one of the map layers is "locked" in the layout which is causing various issues with tool execution.
My question is: Is Pro keeping variables, objects, classes, etc. in memory between tool runs? If so, how do I clear this so each tool run is new? Is the python process left running once the toolbox is opened?
Additional details:
If it is created and added to in memory, then you can use
Delete (Data Management)—ArcGIS Pro | Documentation
del and gc won't occur until the script/tool is done.
Also, if something is being created, you can use the "overwriteOutput" environment variable
According to the mapping docs:
When you use the CURRENT keyword in the Python window with ArcGIS Desktop, you sometimes had to call refreshActiveView to force a screen refresh. This is no longer the case with ArcGIS Pro. All arcpy.mp API changes directly update ArcGIS Pro.
I haven't tried this yet in Pro, but maybe something like
aprx = arcpy.mp.ArcGISProject("CURRENT")
aprx.save()
at the end of your code to force the changes?
I'm quite sure a new process is not started to run a toolbox tool, so yes, python is keeping things in memory - specially those created at the toolbox/tool class level and even in the getParameterInfo method. I've found number of places where locks are left dangling (even reported some with no resolution) and can't find a way around them other than to restart ArcGIS Pro (or restart the python kernel if running in the IDE) - good luck with this one!
I think I traced it down something being done in the update parameters method which I can't debug in IDE, either:
my guess is the cursor is being left open when used via list comprehension.
obligatory - "code was inherited from someone else!"
SearchCursor—ArcGIS Pro | Documentation
use the "with" syntax for cursors...
Search cursors also support with statements to reset iteration and aid in removal of locks.
my guess is the cursor is being left open when used via list comprehension.
That could be an important detail - cursors are usually called using `with` to ensure the entry and exit get hit. Perhaps it's dangling if not closed properly? Curious to see if that caused it.
It was - well, it's currently commented out and execution is running and not leaving layer locks in the map anymore. If I re-enable I'll use "with" and report back.