When I try to clone my project environment in Python I get the following error:
ERROR conda.core.link:_execute_actions(337): An error occurred while installing package 'defaults::ipykernel-4.9.0-py36_0'.
LinkError: post-link script failed for package defaults::ipykernel-4.9.0-py36_0
running your command again with `-v` will provide additional information
location of failed script: C:\Users\Sdwurtz\AppData\Local\ESRI\conda\envs\arcgispro-py3-clone2\Scripts\.ipykernel-post-link.bat
==> script messages <==
<None>
Attempting to roll back.
LinkError: post-link script failed for package defaults::ipykernel-4.9.0-py36_0
running your command again with `-v` will provide additional information
location of failed script: C:\Users\Sdwurtz\AppData\Local\ESRI\conda\envs\arcgispro-py3-clone2\Scripts\.ipykernel-post-link.bat
==> script messages <==
<None>
How can I get this fixed so I can clone my environment and add the Utility Solutions Toolbox to ArcGIS Pro?
Thanks for your help!
Were you able to resolve this issue? I just upgraded to 2.3.2 and get this error. I was previously able to clone with 2.2.4.
Not sure if this was the actual solution, but I tried cloning the environment again and renamed the output folder something different than the default name Esri provides and it worked.
I did but I cheated. I made a copy of the environment and called it the clone and then imported it in.
Stephanie Wurtz
Data Analyst
ACE PIPE CLEANING, INC.
6601 Universal Avenue
Kansas City, MO 64120
office: (816) 768-8813<tel:(816)%20241-2891>
email: stephaniew@acepipe.com<mailto:stephaniew@acepipe.com>
acepipe.com<http://www.acepipe.com/>
A Carylon Company
CONFIDENTIALITY NOTICE: This e-mail is confidential. If you are not the intended recipient of this e-mail, please contact the sender immediately and do not use or disclose the contents of this e-mail for any purposes.
PPlease consider the environment before printing this email.
Helpful information here. We have also been experiencing these challenges in ArcGIS PRO v2.4.1 (and possibly a few versions before this). More specifically, this is the workaround we have been using:
1) In Windows Explorer - Copy the built-in ArcGIS PRO python 3 environment to an alternate locationex -Copy: C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3To: C:\tmp\python\venvs\py3_pro241_copy2) In ArcGIS PRO 2.4.1 - Add the copied python environment as a new environmentProject -> Python -> Manage Environments -> Add -> Choose "C:\tmp\python\venvs\py3_pro241_copy" -> OK
3) Use pythons "wincertstore" module to download the trusted CA certificates on the windows machine*:
In a python interpreter, run the following code to obtain a certificate bundle (pem_file)
import tempfile
import wincertstorecert_bundle_file = r''
with tempfile.NamedTemporaryFile(delete=False) as tf:
for storename in ("CA", "ROOT"):
with wincertstore.CertSystemStore(storename) as store:
for cert in store.itercerts(usage=wincertstore.SERVER_AUTH):
# Py v2
try:
tf.write(cert.get_pem().decode("ascii"))
# Py v3
except:
tf.write(bytes(cert.get_pem(),"ascii"))
tf.flush()
cert_bundle_file = tf.name
tf.close()
print (cert_bundle_file)
4) Use PIP to install needed packages (unable to add them through the GUI in PRO)
Open a cmd.exe
change directory to the copied environment "scripts" folder: cd C:\tmp\python\venvs\py3_pro241_copy\Scripts
Use PIP to install the needed module with the above "PEM_File": pip install <MODULE_NAME> --cert <LOCATION_TO_PEM_FILE>
* The reason step 3 is needed is due to a forward proxy implementation our agency uses that presents all internal clients with a different SSL/TLS certificate than the actual certificate at the site; pip.exe does not trust these internal corporate certificate authority (CA). We have to tell pip what the trusted certificates are and are reading them from the trusted certificate store in windows.
Best of luck!
We recently upgrade to Esri ArcGIS PRO v2.4.2 and the python environment cloning through the GUI seems functional again. No need to use steps #1 and #2.
We are still having problems adding packages through the GUI, so steps #3 and #4 is a viable workaround for us.