Is it possible to relocate the python Toolbox documentation to a sub folder?

349
5
08-10-2019 05:47 AM
DuncanHornby
MVP Frequent Contributor

If you create a Python Toolbox its good practise to document the parameters to guide the users. You do that by editing the item description. This creates an XML file that sits in the folder where the PYT file is.

If your toolbox had let say 100 tools and you judiciously documented them all via the item description then you end up with 100 XML files in the same folder.

Is it possible to move them into a sub-folder and some how have the toolbox point to that location so that when a user interacts with a tool they benefit from all the parameter information?

0 Kudos
5 Replies
DanPatterson_Retired
MVP Esteemed Contributor

custom python tools allow one to specify 'relative' paths for the script locations, but the help is imbedded in the tbx.  I usually find that more convenient since the interface and parameters now support value lists and a variety of other options.  Given you have invested so much in python toolboxes, all I could suggest running a test case with one tool.  Get it working with the xml in the same folder as the toolbox and script, then move the lot to a new folder, splitting the help (xml) into a separate folder and see if relative paths can be supported or a complete rebuild is needed. 

0 Kudos
curtvprice
MVP Esteemed Contributor

The short answer is, no. The XML files are in the same folder as the .pyt, just as other metadata files are in the same container as a dataset.

My feeling is that 100 tools would be way too many in a single toolbox. You may run into performance issues just loading the thing!

DuncanHornby
MVP Frequent Contributor

Dan Patterson‌ I prefer script tools for the very reason you state, that the help is embedded in the tbx file, also you can debug the code (I use pyscripter). Python Toolboxes are a nightmare to debug in and I personally avoid them mainly for that reason, but they do offer superior control over parameters.

Curtis Price‌ when I said 100 tools I was hiding the fact there are actually 400 tools! . I've been helping (OK more like interfering)  with improving the Open Source WhiteBoxTools. One of the developers behind it has written a python script to automate the expose of the 400 odd tools in WhiteBoxTools as a mega Python Toolbox with 400 tools in it.  I think the toolbox needs to improve it's embedded help but as we discovered, the help is stored in an xml at the root level which is understandably not desired as you get 400 xml files cluttering things up.

What is surprising and I think useful for all us to know is that the toolbox takes only about 3-4 seconds to open up and then functions OK. At the moment I'm trying to improve the robustness of the python toolbox tools as whitebox has very specific input needs, the sort of things that can be trapped by the python toolbox before it ever gets to whitebox.

I've only tinkered with some of the whitebox tools and I have say it's impressively fast! Well worth an explore.

DanPatterson_Retired
MVP Esteemed Contributor

Duncan Hornby‌ sounds like something I could contribute to in retirement

0 Kudos
curtvprice
MVP Esteemed Contributor

Some of the best implementations I have seen are to do development as a script tool using the normal structure (as a function, with a __main__ module at the bottom gathering parameters and calling it). This allows both connecting the python script to a tbx as a normal script tool, and also adding it to a .pyt, importing the script tool functions and then calling them in the execute method with parameters AsText. A big plus of this too is the python script tools get precompiled to .pyc the first time the pyt is loaded. The fact that you are calling these whitebox tools as command line (ie most of the code is not in the .pyt or even imported to it) is I why (I am speculating)  the 400 tools load so fast.

0 Kudos