Python and ArcGIS Pro 2.2

9672
3
07-02-2018 11:07 AM

Python and ArcGIS Pro 2.2

At ArcGIS Pro 2.2, the user experience and functionality for working with Python environments and packages has changed from previous versions.


Pristine arcgispro-py3


Python is a critical part of ArcGIS Pro, and is used in many parts of the application. It is also an environment that many users modify by adding and updating packages. Historically you've been able to modify the application's default Python environment (named arcgispro-py3). Unfortunately, this can occasionally result in Python getting into a bad state to which the only solution was to reinstall ArcGIS Pro.

With the 2.2 release, we have modified the experience with the goal to keep arcgispro-py3 in a pristine state. The most immediate and obvious change is that in the python backstage (accessed by clicking Project then Python) if the arcgispro-py3 environment is active, the buttons to install or update packages are now disabled. To enable them you must first create and activate a New environment.

The gain is that if arcgispro-py3 is in a known good state, and if you get your active environment in a bad or questionable state, you can always get back to arcgispro-py3.

New location for environments


In previous versions, the location where Python environments were created was within the ArcGIS Pro install.  For a system install (into C:\Program Files) the python environments were created in C:\Program Files\ArcGIS\Pro\bin\Python\envs.  Installing packages into this folder location requires elevated credentials which was problematic for certain users.

With ArcGIS Pro version 2.2, new or cloned python environments will be created in %LocalAppData%\ESRI\conda\envs. This allows for creation of new environments, as well as add/updating of packages without requiring elevated credentials (UAC). The %LocalAppData%\ESRI\conda\envs location is used for both system and per-user installs.

Command line


The Python backstage delivers a user experience within the ArcGIS Pro application, but some will prefer to use the command line. Below are the command line equivalent to the backstage operations. All of these can be run from the "Python Command Prompt" terminal.

Create a NEW environment

conda create --clone arcgispro-py3 --name %LocalAppData%\ESRI\conda\envs\my_env‍‍‍

Clone an existing environment (other than arcgispro-py3 which is covered above)

conda create --clone %LocalAppData%\ESRI\conda\envs\my_env --name %LocalAppData%\ESRI\conda\envs\my_env2‍‍

Activate an environment for your current command line session

activate %LocalAppData%\ESRI\conda\envs\my_env‍

Activate an environment for the current and all future sessions of ArcGIS Pro and "Python Command Prompt"

proswap %LocalAppData%\ESRI\conda\envs\my_env‍

Switch back to arcgispro-py3 for as the default environment for future sessions of ArcGIS Pro as well as "Python Command Prompt" 

proswap arcgispro-py3‍

Install a package in the active environment

conda install gitpython=2.1.3‍

Install a package in another environment

conda install -p %LocalAppData%\ESRI\conda\envs\my_env gitpython=2.1.3‍


Troubleshooting

The ArcGIS Pro python backstage operations leverage conda to perform the operations.  At this time the messages presented in within the ArcGIS Pro application are not as useful as they should be.  If you're not getting the right behavior from the python backstage, you may want to review the contents of the `%LocalAppData%/esri/conda/conda_debug.log` file.  It may contain more useful information (generated by conda process), and is a a good starting point for any troubleshooting.  Scroll to the bottom of the file to see the latest messages.

Known problems on machines upgraded from 2.1

Unfortunately, problems pertaining to this functionality were discovered on machines that were upgraded from 2.1.x to 2.2.  The problems and how to address them can be found in the following technical support articles.   

We apologize for the inconvenience.

FAQ

Q: After i upgrade to ArcGIS Pro 2.2, i start the application, and the Python window says "Failed to Initialize Python Interpreter" and/or there is an error with the "Space Time Pattern Mining tools". What do i do?

A: "known problems on upgraded from 2.1" above

Q: I clicked the "New" button, but it's been running for minutes... is it going to finish?
A: The very first time you use "Clone" or "New" environment, conda pulls down the necessary packages and builds them.  This process can take some time, particularly if you have a slow connection or a slow machine. Subsequent operations will be significantly faster after the first, but the first must be allowed to complete. In the python backstage, the environment creation will be complete once the spinning progress bar at the bottom of the "Manage Environments" window disappears.

Q: What is the difference between "New" and "Clone"?
A: "New" always creates a copy of the default arcgispro-py3 environment, while "Clone" lets you clone a selected environment.

Q: Can I modify arcgispro-py3 at 2.2?
A: The experience within the ArcGIS Pro application is expressly designed to prevents the modification of the arcgispro-py3 environment. These protections are not there in the command line (will require elevated credentials if editing environment in C:\Program Files), although we caution against it for the reasons stated at the start of this blog, and there is a likelihood that this will cause problems when the machine is upgrading to later versions of ArcGIS Pro.

Q: While using Pro 2.1, I installed a number of packages inside my arcgispro-py3, what happens to those?
A: During the upgrade from 2.1 to 2.2, existing arcgispro-py3 folder will be renamed arcgispro-py3_backup, then a new version of arcgispro-py3 will be installed for use with ArcGIS Pro 2.2.  You can review the contents of arcgispro-py3_backup\Lib\site-packages to determine which packages you was installed into the environment.

Q: I created a Python environment at 2.1, can I use it with 2.2?
A: No, the binaries (particularly envs\arcgispro-py3-clone\Lib\site-packages\arcgisscripting.pyd) are tightly coupled to a particular version of ArcGIS Pro, so environment created at 2.1, will not work with 2.2. You'll need to re-create it using Pro 2.2's python backstage or the conda command line.

Q: Environments which I created in 2.1 still show up in the Python backstage's environment manager, does that mean I can use them?
A: No. See previous answer.

Q: In the Python backstage, I clicked to activate a certain environment, and got the "Restart ArcGIS Pro for your environment changes to take effect" message, but when I restart the application, my active environment is still arcgispro-py3. What happened?
A: Consult the bottom most entry in `%LocalAppData%/esri/conda/conda_debug.log`.

If the machine you're using was upgraded from 2.1 and the the last message in conda_debug.log are "The environment doesn't contain NumPy, which is required for ArcGIS Pro" or "CondaError: Cannot link a source that does not exist." consult the "Known problems on machines upgraded from 2.1"

If the machine you're using was not upgraded from 2.1 , you may encounter this if

  • you interrupt the Python backstage process while it is creating/cloning the new environment*
  • creating a new python environment (at the command line) which is not cloned from arcgispro-py3

* make sure to wait for the progress bar at the bottom of the "Manage Environment" dialog to complete before taking any other interaction with the Environment Manager dialog.

Q: I get this error in my conda_debug.log : SSLError(SSLError(SSLError("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",),),)
A: If your organization intercepts all SSL traffic, then you'll need to add your organization's CRT store to the conda configuration. Consult you system admin for more details.  This is done through this command:

conda config --set ssl_verify <pathToYourFile>.crt‍
Comments

What if the c:\users... folders get wiped regularly because of other network requirements.

Kindof leaves the clone out of the question, and making our students recreate the clone simply to install spyder, jupyter console and other packages required for teaching.  It also rules out using R.. since it isn't in the base installation.

Some questions...

  • Why put in the restrictions?  Who are you trying to help?
  • What are the stats on users fouling up their environment and not being able to get a clean one reinstalled versus the number of users that need more than the base installation?
  • If installed image size is an issue, are there not other packges that don't need to be installed by default?
  • How about an option to install packages or package sets when first being installed? This would simplify multiuser installations rather than everyone cloning and doing it manually?

Yes... it can be done manually through conda... but no one from esri has said... yes you can and you should if the base installation isn't workable.

I'm with Dan on this one.  How in the h-e-double-hockey-stick is limiting the default env to read only a good idea? (But I can back door it with conda; huh?!) I tried creating new and cloned envs to my username\local appdata as described in the Help files and that failed . Sorry ESRI, you guys totally missed the boat here...

Version history
Last update:
‎07-02-2018 11:07 AM
Updated by:
Contributors