Run ArcGIS Desktop (Python 2x), Pro (Python 3x), and Anaconda Python 2.7 all on the same machine?

1508
18
Jump to solution
11-28-2018 08:35 AM
SamGuilford
New Contributor III

I posted this as a comment on this thread, but as the OP's answer involved messing around copying and pasting files, I think it warrants a new question:

I'm currently running ArcGIS Desktop 10.6 (python 2.7) and ArcGIS Pro 2.2.4 (python 3x) on the same machine. I have also installed the Anaconda Python 2.7 32-bit distribution so I can use arcpy in the Spyder IDE. However, this means that some basic tools in Pro now throw errors when I try to run them - I assume because it's trying to access the older version of Python. Does Esri have any official suggestions?

Thank you.

0 Kudos
1 Solution

Accepted Solutions
ShaunWalbridge
Esri Regular Contributor

OK, thanks. The issue is that the PYTHONPATH variable is set. PYTHONPATH is tricky, because it is used in the initialization of Python and will preempt other settings on the machine. We fixed a bug for ignoring PYTHONPATH in Pro 2.3, but unsetting this variable should be enough to fix your machine. You can find the environment variables by pressing Win+Break > Advanced System Settings > Environment variables and removing PYTHONPATH entries from the user and system variable panes if it exists. This page on modifying environment variables may be helpful: https://www.computerhope.com/issues/ch000549.htm 

Once you've unset that, you can check that its correct by closing and reopening. You'll have to fully close e.g. a Python Command Prompt session for these to be flushed, but if it works, your Pro should work again and you shouldn't see any 10.6 references when checking sys.path.

Cheers,

Shaun

View solution in original post

18 Replies
DanPatterson_Retired
MVP Esteemed Contributor

I used spyder for both arcmap (when I had it installed) and ArcGIS pro for some time.

I just wrote scripts as if they were python 3 scripts and paid attention to those tools that differed in their parameters when I needed to have a script run in both map and pro.  I found no glitches in using pro's arcpy in both scenarios.

Are you running into particular problems?

SamGuilford
New Contributor III

Thank you for your response, good to know. Let me reframe. I though it was a Python problem, but perhaps it isn't. Pro throws this error when I try to use Raster Calculator (from within Pro):

I thought this must have to do with the Anaconda Python 2.7 32-bit distribution I have installed conflicting with Pro, which needs Python 3 64-bit. However, shouldn't Pro be calling its own version of Python, regardless? Even if it weren't, wouldn't the immediate problem have to do with the version, not the bit type? To check all this, I have run this same process (raster calculator on the same file) on my secondary computer, which has the same program setup (Desktop, Pro, Anaconda), and there are no problems on that machine. I tried reinstalling Pro and Anaconda, and the problem persists. Any ideas?

0 Kudos
DanPatterson_Retired
MVP Esteemed Contributor

Python for arcmap and hence arcpy is usually installed in a c:\pythonx.x folder

Python for Pro is installed in C:\your_installation_path\bin\Python\envs\arcgispro-py3

arcpy is installed in  C:\your_installation_path\Resources

I would check to see which version you launch.  I do all my scripting in Pro using spyder as well.  

If you want to work with both version of python in spyder, have a look.  I only use pro, so I can't confirm

Working with packages and environments in Spyder · spyder-ide/spyder Wiki · GitHub 

The simplest would be to pip install spyder in your 2.7 distribution so that you are sure you are using the correct version for both.

0 Kudos
SamGuilford
New Contributor III

This wasn't using scripting at all - it was just using the GUI in Pro. I believe I have an idea how to get scripting to work for both python versions, but before I do that I'd like to get Pro back to working as a stand alone program.

0 Kudos
DanPatterson_Retired
MVP Esteemed Contributor

I don't use the python thing in Pro since it isn't clear what it is running

I would hate to recommend doing a ….

Control Panel, Add/Remove programs, 'Repair' ...

'Repair' might fix the ArcGIS Pro problem, but it may undo something that you now have working

0 Kudos
SamGuilford
New Contributor III

I repaired Pro, same problem. Then I uninstalled Anaconda completely, repaired Pro again, same problem. I suppose there might be remnants of Anaconda somewhere? If the rest of Pro works fine, why would Raster Calculator be giving me errors in this way? It seems to throw on this line:

...

    import arcgisscripting

 

ImportError: DLL load failed: %1 is not a valid Win32 application.

 

Any ideas beyond completely wiping Pro from the machine and starting over?

0 Kudos
DanPatterson_Retired
MVP Esteemed Contributor

Sorry, None.  Tech Support I suppose, I suspect there are too many places where conflicts can arise

ShaunWalbridge
Esri Regular Contributor

Sam, are you still suffering from this issue? Do you have a custom environment you're working with, or just the default arcgispro-py3 environment? There are numerous places that Python can be injected into the environment that aren't entirely obvious (system variables, registry keys, cross-linked .pth files) so debugging can be tricky. Can you reproduce this from a command line session of Pro via the Python Command Prompt session? I can give you some starting points before you jump on with support.

0 Kudos
SamGuilford
New Contributor III

Hi Shaun - I have yet to resolve the issue. I did take Curtis Price‌'s suggestion to investigate the syspath, and found that there are two 10.6 paths that have snuck into the Pro environment somehow (see pic below). My best guess is that the problem really has nothing to do with python, and everything to do with Pro trying to access 10.6's 32-bit materials. However, I don't know how this happened or how to reconfigure the paths (I have opened an Esri support ticket, no luck yet). My latest attempt was to uninstall 10.6 completely and then repair Pro, but those paths remain. Any suggestions?Pro syspath

0 Kudos