"condaEnvironmentPath" not working?

321
4
Jump to solution
01-03-2022 03:17 PM
MarkReddick
New Contributor III

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

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
MarkReddick
New Contributor III

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!

View solution in original post

0 Kudos
4 Replies
ABishop
Regular Contributor III

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?

Amanda Bishop, GISP
0 Kudos
MarkReddick
New Contributor III

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

0 Kudos
MarkReddick
New Contributor III

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?

0 Kudos
MarkReddick
New Contributor III

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!

0 Kudos