The answer to this question is yes and no. It is possible with some effort to do everything in Python that you could do in .Net, but easy and possible are two very different things. Following that, the simplest interpretation is no, Python Add-Ins cannot do as much as .Net Add-Ins. However, the tasks Python Add-Ins can accomplish are much easier and faster to implement and test.
From a purely technical point of view, the ArcGIS Desktop Add-In Framework offers the following functionality:
- A well-defined, XML-based schema for describing a series of common desktop integration points and components: Buttons, Toolbars, Menus, Tools, Multi-Item Menus and Extensions, as well as a way to easily connect these in a declarative way from your code to ArcGIS desktop
- A file format and file structure (
.esriaddin
) for distributing desktop customization code.
- A mechanism for installing, verifying and caching installed
.esriaddins
, so if the injstalled Add-In's source file has changed, it will reload the changed file into the local desktop Add-In cache.
- A set of security and authentication mechanisms for the code in Add-Ins: digital signing of
.esriaddin
files, administrative control over what level of authentication is required to permit installation of an Add-In.
What the Add-In framework here lacks is any formal contract of the behavior or functionality behind buttons, etc. When you install the .Net SDK for ArcGIS, you get Visual Studio integration in the form of Add-In Wizards in your project management dialogs, documentation, code snippets, ArcObjects bindings, etc. So once you're past the entry points the Add-In framework provides, a .Net Add-In lets you go the rest of the way with the ArcObjects APIs it also comes bundled with, as well as containing a library of code snippets of common tasks already there to use. There is no such Python Developer SDK in ArcGIS: all of Python's functionality with exposed through arcgisscripting/arcpy and is already bundled in the product. So, where the .Net SDK comes as a large download, the closest thing in Python is the relatively small Add-In Wizard download.
On the other hand, Python is capable of consuming/implementing COM interfaces, but using COM from Python is not bundled with any ArcGIS SDK or documented in the ArcGIS help system. If you're new to developing in ArcGIS, this should be enough of a barrier to entry to push you away unless you really know what you're doing. You can do COM in Python here, but it's close enough to a Turing Tarpit that it's be hard to justify the time spent unless you're an expert-level user already familiar with the ins and outs of COM and ArcObjects.
I'd recommend you look at what you can do with arcpy. You can automate a lot of tasks such as calling Geoprocessing tools and doing batch manipulation of map documents, and Python Add-Ins let you use certain well-defined event sinks and some dialog controls in addition to arcpy's base capabilities. If you can't think of a way to accomplish your task in Python based on what the documentation says (you need some complex user interface interaction or hook into events not exposed in the Python Add-In Wizard or use something only available in ArcObjects), then do your development in a .Net Add-In.
Sorry this is more nuanced than a hard-and-fast yes or no answer, but it should give you some bearing as to whether you should go the Python or the .Net route in your Add-In.
I suppose I should add this disclosure: I designed and developed much of the Python specific functionality to Add-Ins in ArcGIS.
The solution was to include the photos as additional files when creating the map package, and setting the hyperlinks to the anticipated relative path (here it was ..\commondata\userdata, as discussed in the ArcMap help on laying out relative hyperlinks) in the extracted *.mpk folder.
Best Answer
This needs to be split into two parts:
Only ArcGIS can edit map composition (.mxd) -- symbols, colours, labels, legend, embedded tables, etc., etc. -- and geoprocessing tools (.tbx).
However the data can be edited by any program that understands the file formats inside the package, which can be any Esri supported filetype, most common are shapefile, file-gdb, and rasters like geotiff. As the creator of the map package you have control over the file formats included. You could for instance ensure everything is a shapefile which is editable by anything calling itself GIS.
At the receiving end, unpack the .mpk file using any standard de-archiver, might have to add a
.zip
extension for it to be recognized, and explore the contents with the tools of choice. After the edits are done, re-zip, rename to .mpk and send back to source for review.If the only changes are new features added/deleted from existing feature classes or raster values, the source office will see everything as soon as they open the map. New feature classes (or shapefiles or image files) will have be manually added to the map composition, but that's a straightforward process.