0

Recently upgraded to 10.5 ArcGIS. Custom ArcPy Toolbox (pyt) shows the red-x error and will not load. Going to "Check Syntax.." results in this:

   File "[from custom ArcPy Tool .py file]"...
     import matplotlib.pyplot as plt
   File "C:\Python27\ArcGIS10.5\lib\site-packages\matplotlib\__init__.py", line 129, in <module>
    from matplotlib.externals.six.moves.urllib.request import urlopen
   File "C:\Python27\ArcGIS10.5\lib\site-packages\matplotlib\externals\six.py", line 90, in __get__
    result = self._resolve()
   File "C:\Python27\ArcGIS10.5\lib\site-packages\matplotlib\externals\six.py", line 158, in _resolve
    module = _import_module(self.mod)
   File "C:\Python27\ArcGIS10.5\lib\site-packages\matplotlib\externals\six.py", line 80, in _import_module
    __import__(name)
   File "C:\Python27\ArcGISx6410.5\Lib\urllib2.py", line 94, in <module>
    import httplib
   File "C:\Python27\ArcGISx6410.5\Lib\httplib.py", line 72, in <module>
    import socket
   File "C:\Python27\ArcGISx6410.5\Lib\socket.py", line 47, in <module>
    import _socket
ImportError: DLL load failed: %1 is not a valid Win32 application.

Maybe it's normal, but I do notice the stack trace goes from the 32-bit to 64-bit installs of python. 64-bit should be default I think as I installed background geoprocessing and have it enabled.

Seems to be specific to matplotlib as other custom PYTs load fine, but if I add import matplotlib they also run into same error. There is a matplotlib in the site-packages for 64-bit python. Just to be safe I upgraded it via pip to the latest.

Everything is version 10.5.1.7333, including Background Geoprocessing (64-bit). I did a repair install of ArcGIS 10.5 and Background Geoprocessing with no effect. All PYTHONPATH environment variables are pointing to 64-bit python.

  • Did you install the 64bit MatPlotLib? The import error looks like it can find the file but it's not a 32bit DLL as expected. You have mentioned 64bit background processing but are you actually using it? If you're using check syntax it's likely to be 32bit, same if you're running from command line... I would recommend ditching 64bit background geoprocessing altogether, it causes too many complications like this where half your imports are from 64bit and the other half are from 32bit python. – Michael Stimson Feb 27 '18 at 22:38
  • Some other solutions are found here: stackoverflow.com/questions/18898131/… Also consider downloading the premade windows binaries from here: lfd.uci.edu/~gohlke/pythonlibs (They tend to work a lot better). Also try running your script outside of ArcGIS as a standalone; Python GUIs crash inside of the Arc environment. – dslamb Feb 28 '18 at 16:51
  • @MichaelStimson, it's 64-bit and background processing is enabled. Imports shouldn't be coming from 32-bit at all since 64-bit should be used. This toolbox works with lots of big data, 64-bit is basically a necessity. If python was run from the command line it's definitely 64-bit as I checked the environment variables. Seems like it will run in 64-bit but Arc checks syntax in 32-bit which raises the error before I can even load the toolbox. I don't know why Arc likes to switch between 32/64-bit python willy-nilly, but this wasn't an issue before I upgraded to 10.5 (from 10.2). – wowohweewah Feb 28 '18 at 23:41
  • You can see from the paths that it's bouncing from 64bit to 32bit libs, do you get these errors when you execute from CMD? It may be something in your %PATH% and/or %PYTHONPATH% system environment variables that's forcing the read from 32bit libs.. you can change these variables before importing using os.environ.set("PATH","semi-colon delimited list of folders to search") Note: this only changes the path variable for the currently executing python session not for all time or any other processes so it's safe to change without doing permanent damage. – Michael Stimson Feb 28 '18 at 23:58
  • Every instance of Python in PATH or PYTHON_PATH points to ArcGISx6410.5. This includes for user and system. Running the toolbox from CMD with the python command results in no errors, loads, then since it's not a command line tool, exits without doing anything. I'm sure I could whip up a programmatic way of running it via a .py script which would run, but that would defeat the purpose of the ArcToolbox. At this point I'm just trying a uninstall/reinstall of ArcGIS entirely, but the same setup worked w/o a problem for coworkers. – wowohweewah Mar 1 '18 at 0:32
2

Fixed it, though I'm not happy with the solution entirely, it works..

A complete clean reinstall of ArcGIS caused Numpy to fail (in 32-bit). Which ended up breaking every ArcPy Toolbox since ArcPy requires Numpy. While this seemed worse, it sort of gave me some direction.

The basic understanding I have now is that ArcGIS runs in 32-bit python regardless. When running the tool with background processing, it can use 64-bit to run the actual tool, but it initially loads and checks the syntax of the tool in 32-bit. So you have to make sure both your 32-bit and 64-bit Python instances are working with your tool, even if it only actually runs in the 64-bit version.

First thing I did was delete my system's PYTHONPATH environment variable. Having specific paths to the 64-bit Python's Lib folder was probably causing the weird jumping back and forth between 32/64-bit folderpaths when calling libraries. This might come to bite me later, as I believe either I or some program I installed had to create it for a good reason when doing other Python projects, but for now nothing seems broken so we'll roll with it.

Then I did a repair installation of ArcGIS again just to be safe. Probably not necessary step but detailing to be comprehensive.

Now while I could import matplotlib in 32-bit Python normally (e.g. via Python in CMD or PyCharm), the ArcPy Toolbox still had a "Check Syntax.." error about IO Error: Invalid file descriptor. While I'm not sure specifically what that error referenced, the line in question was only a print statement (printing a non-fatal warning). Something about how ArcGIS loads the library probably causes an issue with this, even though it loads fine in the regular Python environment.

C:\Python27\ArcGIS10.5\Lib\site-packages\matplotlib\__init__.py @ about line 1080.

    else:
        print("""
Bad key "%s" on line %d in
%s.
You probably need to get an updated matplotlibrc file from
http://github.com/matplotlib/matplotlib/blob/master/matplotlibrc.template
or from the matplotlib source distribution""" % (key, cnt, fname),
                  file=sys.stderr)

I tried just deleting parts (like file=sys.stderr, all the way to just making it print "Bad key") but no matter what something about the print was tripping up ArcGIS (must somehow be parsing console outputs?). Since it's not technically vital code, I just deleted the whole else clause.

Bit hacky, but now it works anyways. I suppose other option is to delve into updating matplotlibrc, but I found this way simpler -- though I did try updating matplotlib to the latest via pip (yes, forcing on 32-bit python), but didn't fix anything.

  • just intall the library in both 32bit and 62bit instances with pip no? – NULL.Dude Mar 1 '18 at 20:09
  • I think the bigger thing was deleting the PYTHONPATH envir. variable. The error wasn't so much the lack of matplotlib (in either), as I think it was there, so much as the imports flopping between 32/64-bit paths. While I code/program entirely in 64-bit Python so normally that's fine, ArcGIS does use 32-bit at least for the basic GUI and loading toolboxes it seems (though not sure why it was fine in 10.2 but broke in 10.5). Still not sure what I needed the PYTHONPATH var for, but so far nothing is broken (knocks on wood). – wowohweewah Mar 2 '18 at 17:34

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.