Python Add-Ins for ArcGIS Pro

[BryanChastain]

We're just now getting the full functionality of Python in ArcMap via Python Add-Ins, but now everything is moving to ArcGIS Pro and I noticed that there are not any plans to include Python Add-Ins for Pro as well. I do like the new mapping module for Pro, but please also give us the ability to create Add-Ins with Python as well.

[JohnMDye]

In my experience, Python Addins offered me the ability to do a few very powerful things, very quickly and efficiently:

1. Install custom Python Toolboxes and Tools and keep them updated very easily.

In my organization, whenever we created a custom GP Tool, we'd do so by adding it to one of a couple of different Python Toolboxes which we developed. The question then was how to get that Toolbox onto the end users system and keep it up to date as we continued to evolve those tools.

This is where Python Addins came in and really shined for us.

We first used the steps outlined in the Advanced Addin Concepts documentation to modify our ArcGIS Desktop installations so that all installations would have a AddinFolders key under the Settings key in the ArcGIS Desktop registry.

NOTE: The link above references .NET addins but it also works for Python Addins and curiously, this same information was never presented in the Python Addin documentation.

This meant that all of our ArcGIS Desktop installations would now check this AddinFolder location for new Python Addins and install them automagically whenever ArcGIS was initialized if the user did not already have that Addin. If the user already had an Addin installed which was published to the AddinFolder location, then it would be updated if appropriate. 

Next, we created a Python Addin and we'd place those custom Python Toolboxes in the Addin's Install Folder. Then, we'd create a simple toolbar with some buttons on it. Those buttons when clicked would use the pythonaddins.GPToolDialog() function to call up a specific tool from the Python Toolbox located in the Addin's Install Folder. 

This. Worked. Like. Voodoo. Magic. It gave us a framework to build custom GPTools, ship them to our users, and keep them up to date and it was all completely seamless. We created multiple versions of these Addins (Dev, QA, Prod) so that developers could collaborate, users could beta-test and we could easily push to Prod. It was pretty awesome.

It wasn't just toolboxes though. You could ship and keep all sorts of assets up to date in this way. SDE connections, style files, MXDs, data, etc.

But now we can't do that with ArcGIS Pro. Well, that's not entirely true. You can! But you have to build the Pro Addin and Addin interface in .NET and stick your Toolbox (or whatever asset you want to ship) inside of the .NET-based Pro Addin's install folder. This isn't particularly hard but it does add more friction to the Addin building process. You now have to install a whole lot of junk that you'll never use, mess around with XAML and Visual Studio, compilers and all sorts of nonsense that was never necessary with Python Addins.

2. Interact with the ArcMap Event Bus by creating an Application Extension within a Python Addin

Being able to implement custom python code that is executed whenever a particular event fires within the current session is incredibly powerful and being able to do that with Python was amazing. It allowed us to deliver very powerful functionality and iterate on it much quicker than we could have with .NET. It was so easy that I should have known it was too good to be true and wasn't long for this world.

We'd trigger code to run beforeStartup, beforeDocumentClose, onLayerAdded, all sorts of stuff. You could trigger it to only run if the user was using a certain Map Document (or practically any other condition you wanted). If you had group layers set up in your ToC for visibility extents, you could duplicate a layer when added to the map repeatedly for every visibility scale you needed and add it to each group layer so that the user didn't have to add it 20 times and place each layer in the appropriate group layer manually.

• If you needed to do some cleanup or data checkins prior to ArcMap being closed
• If you needed to automatically check out an extension for a user from the license server to enable a certain functionality and automatically return it when they weren't using that functionality
• If you needed to catcg ArcMaps awful, no good, terrible, unintuitive errors (which is no better in Pro) and present an actually useful error message to the user instead
• If you needed to let the user draw on the map and convert it to features or read the geometry as they drew it
• If you needed to do something custom for each data-driven page
• If you needed to interrogate a user's edits to ensure a minimum level of integrity
• If you needed to catch features being deleted and store them in a temporary location in case the user made a mistake and saved their edits so that you could recover the deleted features
• So much more...

Pro Addins probably have all these capabilities and more, but I'm not a .NET Developer nor do I ever want to be one. The closest way I can think of maybe being to access the Pro event bus and have python logic executed when an event fires is to create a .NET-based Pro Addin Application Extension, subscribe to the event threads you need and then write a bunch of arcpy scripts that the .NET Addin will execute and pass parameters that only it can detect to the arcpy script, such as the current MXD or selected layer path and feature id. At that point though, I'd argue that you're probably introducing too many cooks to the kitchen and playing an entirely unneccesary game of hot potato because if your python script produces some result, then you've now got to pass that result back to the .NET-based Pro Addin so that it can do something with it, like maybe add a layer to the map. Totally bonkers. You might as well do it all in .NET. Have fun spending the next 6 months learning enough to be kinda decent but really dangerous at that.

3. Build custom tools

Ah, remember the StreetView Addin? Man, everybody had that thing and everyone had their own take on it. The ability to write a simple tool in Python that the user could use to interact with the map document, draw a geometry, get the coordinates where clicked, catch keystrokes, clicks, double-clicks, etc. all in pure, unadulterated python was awesome. There was almost no limit to what you could do using nothing but Python. I didn't build very many of these at all but I recognized the power of them and gosh, it was nice to know that if I needed to build one I could.

4. Custom Interfaces

The interface capabilities of Python Addins were pretty limited. Toolbars, buttons, menus, tool palettes and comboboxes if I am recalling correctly. Still, it was something to work with and you could quickly get something functional that made the users life easier out the door in a day. You might argue that's still the case with .NET-based Pro Addins as long as you know C# or VBA. To which I say whatever. 

I do recall lots of folks on the Esri forums (god I miss the vBulletin forums) and even GeoNet asking for a more full featured form builder for Python Addins. I might have even been one of them. Esri never delivered on that, probably because they couldn't. There were some attempts with glade and wxPython I recall. I think wxPython was the most stable version but man, it was a lot of code to create something simple. No one wanted to write 500 lines of code to build a dockable window with a tableView.

Cool. Its a hard problem, Esri. I get it. But, no one said "give us an interface builder or kill python addins." 

Esri could've just said "If you want to build a more sophisticated custom UI, you need to use .NET. For Python Addins, this is it." I would've been cool with that.

Ultimately, I really think this has been one of the biggest oversights on Esri's part for ArcGIS Professional.

"Everybody learn Python!" they said.

"Python is the future of GIS" they told us.

So we did. We all went and learned Python. We built GP Tools. We built scripts. We built Python Addins to do all kinds of sh...erm stuff. They told us about Pro and how Python in Pro would be even better because it would be Python 3 and we'd have conda too! We all got giddy with the excitement of being able to conda install to our hearts desires.

Then they shipped ArcGIS Pro 1.0 without Python Addins and we were all like, "Okay, but it's 1.0".

Then, ArcGIS Pro 1.5 came without Python Addins and we were all like, "Hey guys. You...you forgot. The Addins...the..the Python Addins. Remember?" 

Then Esri released the Python API and we all got distracted for a little bit, but we just kept coming back to Python Addins.

Finally, ArcGIS Pro 2.0 came without Python Addins and that was when I knew. That was when I knew that our Python Addins were gone and weren't coming back. 

Rest In Peace Python Addins! We barely knew you.

[JoshuaBixby]

Nice write-up John, thanks for sharing.  On this issue, I think the developer and power-user Pro communities have spoken loudly and clearly.  Esri has always been a bit tone deaf to their user's/customer's needs, but it is still disheartening when you comes across examples like this where existing useful functionality is left behind for all the wrong reasons.

[DanielGreene]

John,

Impressive and powerful rationale.  This part is right on;  "This isn't particularly hard but it does add more friction to the Addin building process. You now have to install a whole lot of junk that you'll never use, mess around with XAML and Visual Studio, compilers and all sorts of nonsense that was never necessary with Python Addins."  

And this part sticks well with my memory;  "Everybody learn Python!" they said.  "Python is the future of GIS" they told us.  And, this is so true;  "Ultimately, I really think this has been one of the biggest oversights on Esri's part for ArcGIS Professional."  I would add that in my opinion their 2nd biggest oversite was dropping support for a Microsoft MDB.  I much prefer file GDBs but MDB support is sometimes necessary for sharing information.

Lastly I truly hope that this will not happen;  "That was when we knew that our Python Addins were gone and weren't coming back."

All I can think of for a reason to not support python add-ins is that perhaps that capability is a threat to Visual Studio developers as it does take away some work opportunities.  I don't like to see anyone lose work but ESRI's priority should be what is the best solution for the long term.  I don't think the answer is Visual Studio for python developers.  Who ever created the python add-in capability for desktop did an excellent job.  Perhaps if ESRI won't build it for PRO someone else may have to but I much prefer it to be part of the ESRI software package.

Dan 

[curtvprice]

It sure would be great to have a distribution package functionality to set up a toolbox and a custom ribbon interactively and share it as a package without coding. That would be slick.

[KoryKramer]

Thanks, John.  I agree with Joshua Bixby‌ - nice write up!  I did just want to clarify that Python add-ins for ArcGIS Pro are still under consideration (the status on this one is accurate). 

[DanielGreene]

Kory - I'm glad it is still under consideration.  I have been playing a bit with visual studio but it seems like overkill.

Thanks,

Dan

[BillPatrick]

We are looking for the ArcGIS Pro python add-in functionality so we can port over some existing tools built for ArcMap via python add-ins. 

[PeteFellows]

I did just discover that Visual Studio Community is free and hopefully will let you install samples and create new add ins.  It is not Python, though. And I have to learn VS and .NET...

https://pro.arcgis.com/en/pro-app/get-started/arcgis-pro-system-requirements.htm

Supported IDEs

• Visual Studio 2017 (Professional, Enterprise, and Community Editions)

[DanielGreene]

Hi Pete,

I think there are limits as to what you can use the free version for.  Will someone please clarify.

I have a version of VS for my learning curve.  What I have discovered is that VS is more difficult to fully understand than the languages it supports such as VB.NET or C#.NET.  I can easily get into and hack one of those programs once set up in VS but I think I would need a course to understand fully how VS is to work and the variety of different options.

Dan

[PeteFellows]

You beat me to it!  I was going to add this to my post:

Takeaway small GIS shop with one or two folks pushing out in house samples to a bunch users can use community but otherwise no.

Licensing:

A) If you're an individual developer (no enterprise, no organization), no difference (AFAIK), you can use CommunityEdition like you'd use the paid edition (as long as you don't do subcontracting)
B) You can use CommunityEdition freely for OpenSource (OSI) projects
C) If you're an educational insitution, you can use CommunityEdition freely (for education/classroom use)
D) If you're an enterprise with 250 PCs or users or more than one million US dollars in revenue (including subsidiaries), you are NOT ALLOWED to use CommunityEdition.
E) If you're not an enterprise as defined above, and don't do OSI or education, but are an "enterprise"/organization, with 5 or less concurrent (VS) developers, you can use VS Community freely (but only if you're the owner of the software and sell it, not if you're a subcontractor creating software for a larger enterprise, software which in the end the enterprise will own), otherwise you need a paid edition.

JUST LET US USE PYTHON!