3

I am currently developing a Toolbox for users who will use it in different versions of ArcGIS (10+ versions). Is there a recommended way to proceed in that situation? My main concerns about that are:

  • Someone had to face that issue before me, how did they overcome the "one version per machine" limitation (ESRI FAQ) ? You can install another version on a virtual machine, but it makes the whole thing more laborious.
  • How to deal with arcpy version differences in the code? Is there a clean way to handle multiple arcpy versions in the same application? All that I can think of is either split completely the tools for the different versions or design some sort of facade/strategy design pattern.

I'm quite surprised I couldn't find more information on how people deal with that.

For people passing by: the Toolbox must be saved in the oldest version (ArcGIS Help 10.1)

  • 1
    The general rule for developing tools for ArcGIS is that if you develop in 10.0, it will work in later versions. However if you develop in 10.2, it might not necessarily work in earlier versions. I learned this the hard way. – pvdev Jun 11 '14 at 14:00
  • Well the thing is, if you are using arcpy functions, there will be some differences. One example would be the arcpy.da.SearchCursor available in 10.1+ but not in 10.0. I'm not sure if arcpy.SearchCursor functions are the same though. So what you're telling me is that if you only develop in the oldest 10.x version, it should be compatible with the 10.x+ versions? I guess that also means giving up on the latest features (such as arcpy.da) but I was hoping to find a way to implement the incompatible parts so that the appropriate piece of code would execute. – 7hibault Jun 11 '14 at 14:19
  • I'm developing in .NET and ArcObjects, and found that everything from 10.0 works in 10.0+. If I try and develop in 10.2, then I come across new interfaces that don't exist in earlier versions, which causes issues. I'm not sure if the same general rule is applicable to developing in python, but I would guess so. – pvdev Jun 11 '14 at 14:38
  • You might look around at some tools that are published. The couple that I just glanced at (ET and Hawth's) basically write a version for each Arc version they wish to support. Depending on the tool that may mean one for 9x and one for 10x, or it might mean a different version for each service pack - it would depend on what changed between versions. A lot of the more one-off tools I've seen target a specific version to solve a problem, and they aren't updated or maintained. – Chris W Jun 11 '14 at 17:18
  • @ChrisW That's something I'd like to avoid, have you found any tool that remains compatible with all versions but manages to use the best out of each version? – 7hibault Jun 12 '14 at 8:31
1

You can use the GetInstallInfo function like so:

    >>> arcpy.GetInstallInfo()['Version']
    u'10.2.2'

Base on the return value, you can dictate which features and functionality you wish to leverage (e.g arcpy.SearchCursor vs arcpy.da.SearchCursor).

In regards to overcome the "one version per machine" limitation, using virtual machines seems the only valid option.

  • Thanks, I guess I'll just use a virtual machine then... And would you recommend a way to use that version information in the global architecture? As there is more to it than just chose between 2 functions once in a while – 7hibault Jun 12 '14 at 8:22
  • Yes of course, there is a lot more to take advantage of in the later versions of arcpy -- the da (data access) cursor was a major advance; another is better access to geometry methods. The point is that if you want to access a better or faster method, you have to know which version you're operating from so that you'll know which methods are available. I use the statement arcpy.GetInstallInfo()['Version'].split)('.')[1] to return '0', '1', or '2' depending which machine I've launched from i.e., the one with 10.0, or 10.1, or 10.2.x installed and use branching logic accordingly. – T. Wayne Whitley Jun 12 '14 at 19:04
  • @T.WayneWhitley Yes, I understood that, what I meant was that I'm trying to find a smarter way to achieve that than inserting some "if (version = 10.0): foo else: fee" everywhere in the code. Especially as I replaced some of arcpy's methods by custom faster (but more complex) pieces of code which would make no sense with arcpy 10.1+'s da. I guess I will just wrap that branching logic and my successive function calls in another function – 7hibault Jun 13 '14 at 7:26
  • 1
    That's right - somehow you have to provide that logic. You could pretty much target which functions to import based on the installed version at the beginning of your main program. It wouldn't be efficient to keep querying the install...do it at the beginning and be done with it. If you later discover a better version-dependent functionality you didn't know about before, wrap that into your imports, etc etc. – T. Wayne Whitley Jun 13 '14 at 11:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.