ArcGISPro Python toolbox problem with module.py cache copy problem

[PaulKennedy1]

Afternoon,

I am developing a toolbox for arcgispro 2.2.3.

I have the regular template .pyt file, and  import a regular module.py file which contains my custom code.  I can run the script just fine in arcgispro geoprocessing facility.

If I then modify the .py file, I then refresh in pro.  The pyt flie appears to be refreshed, but NOT the .py file.  The only way I can get pro to re-read the .py file is to close arcgis and re-open it again.  It then reads the py file.  

It would appear that pro holds a copy of the toolbox in a different folder to the folder I am editing?

If I put ALL my code into the pyt file it is ok, but that is very poor programming practise.

many thanks

pk

import arcpy

import surveyestimator

import geodetic

import math

VERSION = "1.0"

class Toolbox(object😞

def __init__(self😞

"""Define the toolbox (the name of the toolbox is the name of the .pyt file)."""

self.label = "Toolbox"

self.alias = ""

# List of tool classes associated with this toolbox

self.tools = [SurveyEstimatorTool]

def execute(self, parameters, messages😞

"""Compute a survey line plan from a selected polygon in the input featureclass."""

arcpy.AddMessage ("GG Survey Estimator : %s " % (VERSION))

sse = surveyestimator.surveyEstimator()

sse.compute(parameters)

[PaulKennedy1]

Evening,

would appreciate if anyone has any thoughts on this.  I am rather stuck right now.  I would prefer to not have all my code in the .pyt file.  It feels really dodgy and amateurish.

[DanPatterson_Retired]

Is there a particular reason that you are using a pyt?

Is it for a particular functionality that they offer that custom toolboxes don't

Comparing custom and Python toolboxes—Geoprocessing and Python | ArcGIS Desktop 

editing and debugging info is in the link.

I haven't found a use case for pyt over custom yet, so I am curious, since I find editing easy and the toolbox behaves as expected after edits are complete

[PaulKennedy1]

No particular reason.   was using a PYT as the guidance was that python is the future path and as I am a python guy, I thought it was a good fit.

If the custom toolbox re-scans a regular .py file, I would be happy to migrate over.  Do you know if that is the case?

[DanPatterson_Retired]

Paul, I have been using python 3 for years and to re-import/re-load an imported module you can include

importlib — The implementation of import — Python 3.7.1 documentation 

The SO site has a good example How do I unload (reload) a Python module? - Stack Overflow 

You can put this in your main script

from importlib import reload

import yourmodule

then you can have a line which you comment/uncomment while testing

# reload(yourmodule) # uncomment for testing

I use Spyder as my python IDE so you can skip all that by setting Spyder to use complete re-imports by default to ensure that changes are detected in the imported module by the main module.  I do find uncommenting/commenting out the reload line just as easy

/blogs/dan_patterson/2018/01/28/spyder 

For python 2, it is simply a builtin function

2. Built-in Functions — Python 2.7.15 documentation 

reload in python 2.7

[DanPatterson_Retired]

I did a blog or two on simple toolbox/tool creation and script documentation for use in Pro which might be of use. 

/blogs/dan_patterson/2016/05/19/toolbox-creation-in-arcgis-pro 

/blogs/dan_patterson/2018/03/27/script-documenting-it-is-all-in-the-docs 

The use case for custom vs python tools is in the link above... so it is a 'you decide' but I haven't found a good one for pyt's yet.  Until you can use qt or some other dialog creator with arc* products, I tend to use the 'wizard' approach in the custom toolbox since you can screengrab your parameters settings for documentation so you have a visual record

[PaulKennedy1]

Evening Dan

thanks so much for the reload tip.  I will give it a spin and let you know if it works at my end.  Keeping the python code in their natural modules has to be a good thing.  A big bucket of pyt is hardly setting a good standard for future scripts.  

While I like the direction ESRI is taking on python, it still looks very much like a work in progress.  Using a decent IDE + debugger like VSCode would make developing scripts about ten times quicker and the resulting script would be more robust.

One day...