Using Python from Pro and from Desktop on the same machine

6128
11
Jump to solution
01-14-2015 06:40 AM
ModyBuchbinder
Regular Contributor II

Python
that comes with desktop is 2.7 while python that comes with pro is 3.4

They have some differences in basic syntax.

On my machine when you just run Python you gets the 3.4 version (can this be changes?).

When you try to execute desktop python programs (including ESRI tools) you get many errors.

Is there any solution to this?

Thanks

Mody

0 Kudos
1 Solution

Accepted Solutions
ModyBuchbinder
Regular Contributor II

Just found this: Python 3 migration—ArcGIS for Desktop 10.3 | ArcGIS for Desktop

I think it answer most of the questions...

Thanks

View solution in original post

0 Kudos
11 Replies
ModyBuchbinder
Regular Contributor II

Just found this: Python 3 migration—ArcGIS for Desktop 10.3 | ArcGIS for Desktop

I think it answer most of the questions...

Thanks

View solution in original post

0 Kudos
ChristophEffing
New Contributor II

Hi Mody,

I think the ESRI-documentation on this topic is not enough. I have installed pro and 10.3 on the same machine as well. When I try to run my old arcpy-scripts (there are several, made on python 2.7 and arcpy 10.2 32bit) in IDLE, then

nothing runs, because IDLE is looking on python 3.4 and arcpy 10.3. When I run the scripts within ArcGIS 10.3 Desktop it works, because ArcGIS 10.3 Desktop takes the 2.7 python library and the old arcpy 32 bit library.

Of course I would like to use IDLE as I did before. When I migrate one of the old scripts to arcpy 64 (2to3) and correct all the new classnames and so on, then I get

RuntimeError: Not signed into Portal.

So like in ArcGISPro I have to sign into arcgis-online or my own portal (if available) wiht my named user.

I would do this, if I knew how ...

Any ideas?

Or is the ESRI strategy to do all scripting within ArcGIS desktop or ArcGIS pro ...?

Then they should let us know ...

or tell us how to switch the IDLE-IDE to pyhon 2.7 ...

Best regards from Berlin,

Christoph

0 Kudos
ChristophEffing
New Contributor II

Hi again,

found a workaround:

When I opened my python scripts I used right-mouse-click/IDLE. On my machine this opens IDLE on Python 3.4 and so with the new arcpy64bit objectmodell.

When I open IDLE within the ArcGIS-Python 2.7 startmenu 

(C:\Python27\ArcGISx6410.3\pythonw.exe)

and then "Open..." in the "File" menu ... go to my script location

... it works ...

Documentation on this would have been fine. And that the new 64bit-arcpy-library has the

same name than the old 32bit-arcpy is a NO-GO, isn't it?

Best regards, Christoph

0 Kudos
JoshuaBixby
MVP Esteemed Contributor

Even before ArcGIS Pro, this same situation would occur when installing 64-bit Background Geoprocessing, although those 64-bit libraries broke much less 32-bit code than ArcGIS Pro.  The issue arises because the last, or most recently, installed ArcGIS application changes the file-type associations and shortcut targets to the Python interpreter it installs.  You can always go into the file-type associations and change the default Python interpreter that is used for running or editing Python scripts.

0 Kudos
MichaelVolz
Esteemed Contributor

When running your scripts in the Pro associated python, did you need to make a call to AGOL to get your license as the licensing structure is different for Pro (Named Users in AGOL) as opposed to possibly a concurrent or standalone desktop license?

I had this question answered by ESRI technical support.  If you port over a python script from desktop to run on a machine with Pro, you would be unable to programmatically access AGOL to obtain a license in python 3.4 that is installed with Pro.  You would need to be logged onto AGOL through the Pro desktop application in order to have a license available to run the script.  This means if you have scripts that run at night or on weekends, you would need to stay logged into AGOL (This limitation of Pro's python version definitely needs to be addressed).

0 Kudos
JoshuaBixby
MVP Esteemed Contributor

I think you were given some bad information.  Running ArcPy scripts, from a licensing perspective, isn't much different on Pro than with ArcMap.  Just like in ArcMap/ArcCatalog, ArcPy needs access to a license to load.  If one had a Single-Use license or borrowed a Concurrent-Use license, then the license was already on the machine.  If one was setup for Concurrent-Use licensing and didn't borrow a license, ArcPy would contact the license server to acquire a license before running.  ArcGIS Pro behaves similarly.  I don't have to be logged into ArcGIS Pro to run a script with ArcPy, I just have to have ArcGIS Pro configured properly to obtain a license from either AGOL or a licensing Portal (but Pro does have to save your credentials for this background login to work).  I would have to double check, but I also believe that ArcPy will use an offline Pro license if someone takes their license offline.

In short, you do not have to have Pro actively open and running to run scripts with Pro ArcPy, or ProPy as some of the filename paths sort of refer to it.

MichaelVolz
Esteemed Contributor

The only reason why I started a technical support incident with ESRI is because the script I migrated from Desktop to Pro threw the error:

Runtime Error: Not signed into Portal

after I signed out of AGOL through Pro and then ran the python script.

The support analyst then started providing me with code samples to log into AGOL to obtain a license, but after consultation with other support analysts, the original support analyst said the code to log into AGOL from python 3.4 (bundled with Pro 1.4) was not yet available.

Do you have some code samples to prove this explanation from ESRI technical support not to be true?  Any feedback on this topic would be greatly appreciated.

0 Kudos
JoshuaBixby
MVP Esteemed Contributor

Do you have Pro setup to automatically sign you in or does it prompt you for credentials each time?  If the former, the script will simply login to the licensing portal in the background and run. If the latter, it will fail and generate the error you see.

Why are you actively logging out of your licensing portal instead of just closing out of Pro when you are finished? 

0 Kudos
MichaelVolz
Esteemed Contributor

You don't think there is a security risk in staying logged into AGOL indefinitely?

0 Kudos