update cloned python environment(s) while updating arcgis pro

[Mascht]

Hi esri folks,

thank you very much for including a python package manager into ArcGIS Pro!

Unfortunately, my installed packages have got lost just by every update of Pro since then, because cloned python environments haven't been taken into account during the update process...

Happy GISing,

Mascht

[Mascht]

High Esri folks,

many thanks to everybody involved in implementing my Idea. Worked nicely after updating Pro to 3.0.

Happy GISing,
Mascht

[FakeName]

Definitely didn't work when I updated from 3.1.x to 3.2.0. The "update" simply deleted the clone after about 10 minutes 😞

[ShaunWalbridge]

@FakeName I took a look at this, and I think I've identified what the issue is. If you have any existing resources open that reference the environment directory, it will currently cause a failure. So for example, if you have a command line prompt at the working directory of the environment, that will lock the location and Windows won't be able to delete the folder. There is a second bug which is that the restore doesn't happen in this case either. I have local fixes for these issues and will look to get them into software, for now, here's a workaround:

1. Your environment doesn't get deleted, it is archived first. If you navigate to %LOCALAPPDATA%\Esri\conda\envs, you should see a file called <env name>.tar.bz2. This is a conda-pack archive of your environment, you can extract it with current builds of Windows 11, 7-zip or by using conda pack to restore your old environment from Pro 3.1.

2. Once you have that in hand, from the Package Manager interface of Pro you can add the environment back to the environment list. If you do this, then ensure that no other resources are referencing that environment, the upgrade should work as expected.

Sorry for the trouble and will look to fix this soon.
Cheers, Shaun

[JTessier]

@ShaunWalbridge is this a bug you are tracking?  If so what product version do you see it for?  We struggle mightily with the python clones  everytime we upgrade Pro.

Thanks!

[ShaunWalbridge]

@JTessier the specific issue that @FakeName identified was fixed in Pro 3.3, which is if you had active things running against the environment that you're trying to upgrade it wouldn't correctly get upgraded and just leave you with the backup. It will now in that case fully restore the environment back to its original state, and the upgrade should work once those file handles are unlocked first.

If you see specific issues with upgrading your custom environments, can you share details on what the failures are, and what kinds of packages are present in your environments?

[JTessier]

Thanks Shaun, will do, we are just in process of upgrading Pro to 3.3 and noticing that our python scripts silently stopped working and determined the python clones were not upgraded along with the default clone.  More to come, but hoping the next upgrade goes smoother.

[ShaunWalbridge]

@JTessier Got it. Custom environments can't be directly upgraded by the software upgrade process, because they weren't created by it (MSI files specify the files they have written, and those are the things they can change). To upgrade custom environments, follow the instructions provided here: https://pro.arcgis.com/en/pro-app/latest/arcpy/get-started/upgrade-an-environment.htm

In most cases, it should be as simple as clicking the upgrade button within the UI, but it is possible to invoke from the command line or with a script as well. This process should migrate both custom installed conda and pip packages.

[dbKlingdom]

Hello, During our last upgrade of Pro to 3.3.1 we had to use the UI in Pro to upgrade the Clone However this Process created a new Clone-1, which is not ideal.  We would like to have only the one Clone.

[JTessier]

Agree with @dbKlingdom  above.

[ShaunWalbridge]

@dbKlingdom @JTessier The intended design is that you do only have one clone, the upgrade interface should look like this with a button to click in order to start the upgrade:

That should backup the environment and create a new one in the same place with the same name. If you're not seeing that behavior, I would consider it a bug.