Hi,
I am creating a custom python GP toolbox that relies on other modules I have built.
Based on the Esri recommendation I am have cloned the default server conda env and installed my modules to the cloned env using pip. Everything installs fine and i see the modules listed in the env.
Following the steps here I then use the "condaEnvironmentPath" property to tell server to use my cloned environment that includes the installed modules. However when i try to start the service i get:
"Geoprocessing Service initialization failed"
"The toolbox did not load"
"Failed to construct instance of service"
If however I use the main non cloned conda environment and install my modules there, everything works fine, the service starts and I am able to call and use the GP service via my web application as expected.
It only fails it I try to use the cloned env and the updated "condaEnvironmentPath" property in the service details.
I would like to follow the Esri recommended path of not touching the default env but this environment per service approach does not appear to work for me. Has anyone had any success with this?
thanks
mark
Solved! Go to Solution.
Been talking with Esri folks, look like this is a known issue in 10.8.1 and probably 10.9. Unclear on status in 10.9.1 at this time. BUG-000137332
Short term workaround is to change the cloned env in use for all services via "proswap newenvname" rather than using condaEnvironmentPath for just one service. Not ideal long term for systems with other custom python gp tools installed (with other modules dependencies) since this would break these other tools.
Closing discussion, thank you for all assistance!
Hello Mark,
This is just a stab in the dark, but have you tried adding the new conda path as the "python" variable in your environmental variables on the server?
Hi Amanda,
Not a python expert here but if I'm following this would be a system/server wide change vs specific to just my single service which is the supposed to be the point of the condaEnvironmentPath property.
Apologies if not following,
mark
Stepped away for few days and came back to it.
Confirmed that it is simply ignoring the condaEnvironmentPath property specified in the documentation....
With the setting in place and the service failing to start, if I jump over to the ArcGIS account and run pip on my modules into the default esri environment and jump back over to my domain account the service then starts just fine. So it is still looking for the modules against the default env.
So not sure if documentation is wrong, parameter name maybe wrong, bug, or missing some step to refresh envs and let esri know about?
Been talking with Esri folks, look like this is a known issue in 10.8.1 and probably 10.9. Unclear on status in 10.9.1 at this time. BUG-000137332
Short term workaround is to change the cloned env in use for all services via "proswap newenvname" rather than using condaEnvironmentPath for just one service. Not ideal long term for systems with other custom python gp tools installed (with other modules dependencies) since this would break these other tools.
Closing discussion, thank you for all assistance!