How to delete geoprocessing cache in ArcGIS Pro?

[RyanDavis1]

Hi - Can someone tell me how to delete the geoprocessing cache?

I'm developing a Python toolbox that has supporting .py files.  For whatever reason, Pro holds onto old versions of the supporting .py files.  Using importlib reload and closing/re-opening Pro does not help.

In the past I've deleted my entire C:\Users\userID\AppData\Local\ESRI folder to solve the problem, but that's overkill because it deletes a bunch of personal settings I would prefer to keep.

This has been a problem in multiple versions of Pro, but I'm currently using 2.9.2 FWIW.

Thanks,

Ryan

[Shaun-Walbridge]

Could you provide details about how your project is laying out and what kind of information you're seeing as cached? There is a separate concept of the "Geoprocessing cache" but that relates to the toolboxes and not Python code. Python itself caches code, but typically either import lib or reopening the application is sufficient to clear this. Finally, Python itself does perform byte code caching, but those caches should be invalidated in any typical execution. It may be the case there is some tricky code organization issue which would exhibit as this behavior, but if you can provide details we can dig in further.

Cheers, Shaun

[RyanDavis1]

Hi @Shaun-Walbridge,

It's been a while since I posted this, but this is still an ongoing problem.  I also delete my .pyc files but that doesn't seem to help.

I'm updating scripts and layouts, but the tool wants to hold onto old versions of the scripts.  My first clue it's using an old version of the script is an arcpy.AddMessage right at the beginning that includes the last update date of the tool.  But, it will bring in versions of layouts and maps that don't include my latest updates.

I'm now on Pro 2.9.4 since posting this.  I'm also using git if that could have anything to do with it.

Thanks,

Ryan

[ShaunWalbridge]

Try starting a Python Command Prompt session, then run `python -v` and import your script from that environment. You should be able to see every import that is performed, and identify if your code is coming from some other location than where you expected based on the Python import path. Or please share some of your code so we can see what might be the cause.

Cheers, Shaun

[RyanDavis1]

Hi @ShaunWalbridge,

I've found the problem here, but I'm at a loss as to how to fix it. I may have to create a Tech Support ticket because I would describe it as a bug.

Summary: 

• I have two, separate Python toolboxes with similar file paths and file names on my PC.
  • One is a development toolbox while the other is for staging/production.
• When I load/run the dev PYT, it is referencing the files (.py, .pagx, .lyrx, etc.) in the prod PYT's folder.

This behavior is rather inconsistent. I'm not sure if it's a Python issue or something wrong with ArcGIS Pro folder connection configuration or I'm totally doing something wrong.

Sometimes after a restart, the problem goes away but not always.

The folder structures are something like this:

dev_folder
- DevPythonToolbox.pyt
- subfolder
-- __init__.py
-- module.py
-- other supporting files

prod_folder
- ProdPythonToolbox.pyt
- subfolder
-- __init__.py
-- module.py
-- other supporting files

The relevant code is like this:

# Top of DevPythonToolbox.pyt
import arcpy
from subfolder import module
from importlib import reload  # for dev only
reload(module)  # for dev only
...
class Tool(object):
    def __init__(self):
    ...
    def execute(self, parameters, messages):
        """The source code of the tool."""

        from subfolder import module  # for dev only
        from importlib import reload  # for dev only
        reload(module)  # for dev only

        if __name__ == "__main__":
            module.main(parameters)

        return

Is there a place where these file paths are cached or indexed? I have already tried deleting Local Caches and Index folders in C:\Users\user\AppData\Local\ESRI.

Thanks,

Ryan

[ShaunWalbridge]

The caches that Pro maintains don't have any relationship with the caches that Python code uses, so you will be fine leaving those alone. The Python module import system is somewhat complicated, and I would do some investigating to see what is happening when you run your imports, when you run from subfolder import module it may not be importing what you are expecting it to import. Depending on how your sys.path is configured. You might check that just after you run that import line what the value of these variables are:

import sys
print(f"sys.path entries: {sys.path}")
print(f"path of imported module: {module.__file__}")

If the path of the imported module is your other copy, then you've found why what you're loading differs from your expectations. You have a few options to sync these up, perhaps the simplest is to use sys.path.insert(0, 'path-to-thing-you-want') in your code to prepend the path to the custom object. You may also be better served using the Python tooling for working with packages and make this a package depending on how complicated your deployment is for this. If this is only local, you could also have the dev and release builds use different names to ensure clarity.

Cheers, Shaun

[RyanDavis1]

Hi @ShaunWalbridge ,

I appreciate your suggestions. They did confirm my suspicions that the dev toolbox was referencing the prod files.

Based on that information, I figured out that the prod toolbox was listed as a favorite to load to all new projects. I typically drag my dev folder into Pro each time for testing. It seems that Pro prefers the file names and paths of the favorite production toolbox.

I have since removed it from my favorites, and so far the dev toolbox is referencing the correct files.

I created a support ticket earlier today and will be following up with this information.

Thank you for your help.