1

Desktop environment:

Windows 10 64-bit, ArcMap 10.3.1, Python 2.7 32-bit (installed by ArcMap)

Server environment:

Windows Server 2012 64-bit, ArcMap 10.3.1, ArcGIS for Server 10.3.1, Python 2.7 32-bit (installed by ArcMap), Python 2.7 64-bit (installed by ArcServer)

My custom GP tool script is calling a 3rd party set of open source python libraries that have been developed to work within Python 2.7.x 32-bit framework. The GP tool works as expected on my desktop PC. I would like to publish my custom GP tool as a service on my remote server with both ArcGIS for Server 10.3.1 and ArcMap 10.3.1 installed on it. I am well aware that ArcGIS for Server demands a 64-bit framework for Python, so my question is: what would be the best way to publish my custom script tool (working on my desktop PC) as a service to be served within a web application (i.e. GP widget) without encountering conflicts and errors?

6
  • You don't mention the 64-bit install of your custom tools.
    – Vince
    Commented Jul 5, 2016 at 20:43
  • &Not sure I understand Commented Jul 5, 2016 at 20:47
  • You cannot publish a Python script on a 64-bit server unless it has the same packages as your 32-bit client. What you appear to want can't be done.
    – Vince
    Commented Jul 5, 2016 at 21:04
  • @vince I can certainly install the same packages on the Server, since ArcMap on the server will install a 32-bit Python. But I am wondering whether those packages HAVE to be 64-bit and not 32-bit in order for the GP tool to be published and working within the ArcServer infrastructure...I hope I explained myself. Commented Jul 5, 2016 at 21:20
  • Server will NOT use a 32-bit Python, no matter how many of them you install.
    – Vince
    Commented Jul 5, 2016 at 21:40

2 Answers 2

3

What we have typically done at my organization, is on a shared location that is accessible by all of our servers is set up a folder with third party python modules and temporarily append that path to the PYTHONPATH like so in the GP Script:

sys.path.append(r'//server/path_to/third_party/modules')

The other option is as you mentioned would be to install the packages locally on the server in the site-packages folder. This may not be the best solution as the site-packages folder will probably be getting replaced each time an ArcGIS Server upgrade happens.

However, @Vince is correct in that ArcGIS Server will only use the 64 bit python installed on that machine.

If you really do need to use 32 bit Python server-side, I do have one idea that is a little outside of the box. I recently began working with Python Flask as an alternative to GP Services. Flask has a lot of capabilities, including the ability to set up your own RESTful services using Python on the back end.

It is super easier to use and doesn't have a lot of the overhead that often comes with GP Services. Once started, the service will also restart itself if it detects changes to your python app script, so no need to republish!

We are currently testing some apps where we have a JavaScript client making calls to the REST service and it works pretty well. It is easy to secure too as we created our own token-based authentication this is authenticating against our Active Directory.

2

I think the key concern, as raised by most people here, is whether or not your 3rd party libraries are x64-compatible. (Some libraries are simply pure python code that is architecture independent while some are not.)

Since you just stated that you are using a pure x86 python environment, I would suggest you to verify the 3rd party libraries can run in x64 env first.

As a quick test, by installing the Background Geoprocessing (64-bit) package for ArcGIS Desktop, you would be able to sort of test your program in the x64 environment. Please find more information here

If you are certain that your code can run in x64 python, by appending the path or installing the 3rd party libraries to site-packages folder (as suggested by crmackey), you should be able to publish directly to ArcGIS Server as a geoprocessing service.

Hope it helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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