Latest Contributions by JohnMDye

Agreed. I've always been a proponent of just using the organization name value as defined in the org settings by the admin, but even 'add from this portal' would be an improvement over the generic 'organization'. That's far too broad of a term, especially if you've got multiple portal2portal collaborations going on. ... View more

I'm actually just tinkering around. I just finished the SalesForce iOS Development Trail and wanted something to play with. I'll definitely fetch from the repo once 1.1 is merged into master. For now, I'll keep toying with the current version since I'm not doing anything serious. Much appreciated heads up! ... View more

First let's ensure the ArcGIS.bundle is referenced by the project only one place. The error that reads starting with "Multiple commands produce ..." leads me to believe the project is attempting to build with two references to the ArcGIS.bundle. What we need to do is to delete the second reference. The application in its current condition is configured to reference the ArcGIS.bundle from within the 'Resources' folder. Based on this path in the error ('/Users/jmdye/Git/data-collection-ios/data-collection/ArcGIS.bundle') it appears you might have added a second reference to the ArcGIS.bundle located in the top level project folder? If this is the case, i'll ask you to delete this reference. Bingo. This Stack Overflow response to a similar error tipped me off, but your response is spot on and it comes with an explanation! Even though I'd corrected this issue, I didn't understand what was wrong in the first place, so thank for taking the time to write out those detailed troubleshooting steps, super helpful! ... View more

Follow me so I can shoot you a DM ... View more

That makes sense. Could you not just add ArcGIS Pro's Conda env to your path and then conda install --offline c:\my-awesome-package.tar.bz2 ... View more

That makes sense. Could you not just add ArcGIS Pro's Conda env to your path and then conda install --offline c:\my-awesome-package.tar.bz2 ... View more

Why don't you just go get a Trial License? That should give you 21 days of ArcGIS Desktop at the Advanced level. If that's not enough time, just sign up for another trial afterwards. ... View more

Bueller? Bueller? Anyone? ... View more

Perhaps some ignorance speaking here, but is the top answer posted here not sufficient? python - How can I host my own private conda repository? - Stack Overflow  ... View more

Perhaps some ignorance speaking here, but is the top answer posted here not sufficient? python - How can I host my own private conda repository? - Stack Overflow  ... View more

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. ... View more

I agree with that. Try/Except is useful when used appropriately and I would agree that if Esri is going to have Try/Except blocks in their code examples, they should be demonstrating how to use that properly. There's definitely no point to the try/except blocks in many of the examples and it teaches new developers bad habits. ... View more

Perhaps this is just my own inexperience speaking, but I don't find try/except statements to be useless. The particular example that Paal Pedersen raises is certainly useless, but try/except in general, when used appropriately can be useful. In GIS, we often can think of multiple ways to proverbially "skin the cat". Try/Excepts can be useful for getting the desired result through any one of those many processes. They can also be useful for handling very specific errors that one might encounter when performing a workflow. While I agree with Paal that this particular example of try/except should be removed, because it is useless. I might go a step further and say that instead of removing the try/except statement, perhaps demonstrate how it can be useful for handling a specific error or getting the same result through a different process if a particular exception is thrown. PS. No cats were harmed in the making of this post. ... View more

+1 ... View more