I have a python script that runs in a conda environment that seems incompatible with ArcPy. This python script runs great in my environment when launched from ArcGIS Pro's Python Command Prompt.
However to distribute this tool to others, I am trying to enable launching the python script from a script tool in the GUI. To do so I am using a preliminary script to record the parameters entered into the GUI to a text file and then launch a subprocess that reads a *.bat file that changes the environment to mine and launches the original python script.
The subprocess successfully opens a terminal, changes the environment to mine, however when the original python script runs, it cannot import typical packages like numpy, giving this error:
ValueError: failed to parse CPython sys.version: '3.7.12 | packaged by conda-forge | (default, Oct 26 2021, 05:37:49) [MSC v.1916 64 bit (AMD64)]'
Investigating the environment shows that even though conda shows that I have switched to my environment, it is still trying to import packages from the default ArcGIS Pro environment. I don't understand what is happening, especially considering that there is no problem when running out of the Arc supplied Python Command Prompt (or the windows cmd.exe for that matter).
There seems to be some fundamental difference between the ArcGIS Pro GUI launched prompt and the others, although the only difference I can find lies in this particular behavior.
I was hoping someone might have some suggestions about how to get my python script launched successfully.
Thank you for your time!
Normally I would do something like this by specifying a full path to python, that loads the correct environment and in fact it works perfectly when run directly from a cmd or bash shell. For example here is my condarun.bat file and my condarun.py file.
import sys with open('C:/TEMP/tmpout.txt', 'w') as fp: fp.write(sys.version + '\n') fp.writelines([p + '\n' for p in sys.path]) print('python ran') exit(0)
The output file C:/Temp/tmpout.txt has the expected text, here is one line for example. The important thing is that it's loading my arcgis_tools environment correctly
I ran a bunch of tests this morning, every way I could think of to get it to run my own python environment, and every time, they substitute their own when I run inside ArcGIS Pro. For example,
Next I tried to bypass it by running a python.exe directly from the "Script Tool" as the Script File and passed in the name of the script as a parameter. Still fails. I tried running cmd.exe and passed in the name of the batch file, this fails because it never completes, just spins.
My conclusion is that Esri is once again
preventing from doing what you need to do protecting you.
I am interested in this as well. The use case is building a custom tool for use by other desktop end-users within my organization. Would like to be able to maybe push out a custom env for them to use on demand?
I'm working on something similar and I am at the point of automating the cloning of the default env, package installing, and setting the Pro Project's active python environment to the custom env. conda is a frustrating little black box but using the steps provided by Hannes here:
Generate a list of additional packages installed in your current environment,
with the conda command:
>>> conda env export > env.yaml
(Optional) If you have additional dependencies installed through pip,
find those with pip freeze:
>>> pip freeze > requirements.txt
Create a new environment by cloning arcgispro-py3, and activate it:
>>> conda create --clone arcgispro-py3 --name my-env --pinned
>>> activate my-env
Add back missing conda packages from your current environment:
>>> conda env update -n my-env -f env.yaml
(Optional) Add back missing packages from pip:
>>> pip install -r requirements.txt
(Optional) Make it the default for the ArcGIS Pro application and the
"Python Command Prompt":
>>> proswap my-env
I am able to set the custom configuration made in Pro SDK to activate the python environment that is needed. I am working on figuring out how to execute these commands in a subprocess or bat file, either through C# or python.
Surprised that they don't provide any means of cloning the env through the Pro SDK, since its all about customization and esri's best practice is not to touch the default python env.