nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

"condaEnvironmentPath" not working?

MarkReddick

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

Trouver plus de publications taguées avec

Accepted answers

MarkReddick

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!

All comments

ABishop

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?

MarkReddick

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?

MarkReddick

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

MarkReddick

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

Closing discussion, thank you for all assistance!

AlinaTaus

Just curious if you've been able to find a resolution to your issue. We are running into a similar issue publishing a geoprocessing service to Server 11.3. More specifically, we can't seem to get the cloned server conda env to be recognized at all, despite following ESRI's documentation (same article mentioned in the original post). I've done some testing around the "condaEnvironmentPath" property, but setting that to the cloned conda causes the tool to fail with this error message: ERROR 000816: The tool is not valid.

In one of the tests, we created a simple tool that did not import any third-party packages but added a print statement to return the conda environment being used (using sys.prefix) The tool was published and did not return any errors. Executing the task from the REST endpoint showed that the default conda server environment "arcgispro-py3" was being used instead of the clone that was created and set as active.

I've opened a ticket with ESRI, but was curious if the BUG-000137332 they reported as being closed at 11.1, is still an issue at 11.3 or if anyone else is experiencing issues with a cloned conda environment for Server.

mattprice

Hello, We are having the same issues with 11.3 condaEnvironmentPath as well. I am wondering, do you have the outputDir and jobsDirectory on the C drive (default). We pointed all our outputs to another drive mapping, and I am wondering if this could be causing some issues. So instead of C:\arcserver\directories\arcgisoutput its \. Thanks for any info you can provide.

mattprice

I wanted to follow up on this. We were able to get it to work. Our issue seemed to be that we had all of our output going to a D drive, OutPutDir, JobsDiretory, etc but we were installing the cloned python to the C drive. When we installed the clone on the D drive to match the output location. I think it may have something to do with the conda enviroment variable swapping the ArcServerPath variable which is set to C:\program files\ArcGIS\Server\.

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.