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; } } }

Upgraded to 2.3 and I cannot use my previously cloned conda environment

ZacharyHart

Has anyone else had this problem? I upgraded from 2.2.4.

I do have a case open with Esri, but I started that case on 1/30/19 and they've still not come up with an answer yet so I thought I'd try the community.

I can create a new environment but I cannot get Pro to use my previously cloned environment. There is a warning that there is a 'Version Mismatch'.

Are you supposed to reclone your default env for every new version of Pro? And that would mean having to download packages, reconfigure Jupyter notebooks etc.

Find more posts tagged with

Accepted answers

All comments

DanielAragon1

Generally speaking, I had the same issue where upgrading to pro 2.3.0 broke my ability to run an arcpro 2.2.2 conda environment. I don't have time to endlessly debug, so just reinstalled 2.2.2 and that got me up and running again. However, I have tens of thousands of line of code that are reliant on this conda environment (and the unspoken responsibility to client and budget). Thanks to Dan Patterson for his dedication to these types of issues - it's helped us get to where we are. However, without a more robust integration of arcpro/conda that can withstand these minor upgrades (or prepare us for breaking changes), I'm left looking for other solutions in the future. ESRI, please prove me wrong and I will happily be an arcpro cheerleader.

BrianKaplan

This did not work for me. It went from version mismatch to broken environment after I performed the steps. I ended up deleting and creating the environment in Pro. Before I did that, I saved the env.yaml file from step 4 and then updated the environment using step 9 from the env.yaml after creating the new environment. I also did step 5 before deleting the environment. I tried to ignore the mismatch environment and just create a new environment but it failed (file explorer created a new environment folder but it must have been incomplete because Pro did not recognize it. Deleting the old environment did the trick for me.

ZacharyHart

I just found your reply! Sorry I missed this. I'll try this as soon as I can (lots of irons in the fire). Thanks a bunch.

KoryKramer

Hi Zachary Hart. I checked in with our dev team and they wanted to share the following steps:

1. Reset your ArcGIS Pro environment back to the default (arcgispro-py3). Close Pro.

2. Launch the "Python Command Prompt" and activate your out of date environment:

activate <name>

3. Change directory to the default user location for environments:

cd %LocalAppData%/Esri/Conda

4. Export the environment to a file:
conda env export > env.yaml

5. Get a list of any pip installed packages,:

@echo writing pip installed packages to pip.txt && conda list | for /f "usebackq" %f in (`findstr "<pip"`) do @echo %f > pip.txt

6. If you want to be extra safe, you can make an archive of the environment you’re upgrading at this point. Then, activate the root environment so we can remove the original:

deactivate

7. Now, we will remove the out of date environment:

conda env remove -n <name>

8. Create a clone of the default 2.3 arcgispro-py3 environment:

conda create --name <name> --clone arcgispro-py3

9. Overlay the packages that were in the old environment:

conda env update -n <name> -f file.yml

10. Set this environment as the default for Pro (if wanted):

proswap <name>

11. The last step is to look at the list of pip installed packages in pip.txt, and install those if needed with pip install <package name>

DanPatterson_Retired

So it would troll you previously installed packages and find the differences between new and old clone? What about the base install? Unless it did that, it wouldn't help us. We do conda installs of packages in the default esri provided env. We have to deploy a base Pro install with all the packages we need and having to deploy a clone along side isn't useful or needed for us. In a teaching environment, It is just way faster to reimage the machine should things go wrong. So far we haven't found anything in the science-based packages that has caused any issues. I understand the reason for protecting the casual user from themselves, but it is of little use to us and the unadvertised workaround is just fine.

AdamEversole1

Dan Patterson‌, Zachary Hart‌

Hey Guys, I worked with Zac on this support ticket, We got a enhancement logged:

ENH-000120281 : ArcGIS Pro 2.4 is unable to use old Python environments yielding warning for Version Mismatch. Please allow future upgrades of ArcGIS Pro to also include previous python environments in the process.

For any accounts running into this issue please feel free to contact our support team to get your account attached to this record.

Hope this Helps,

- Adam

DanPatterson_Retired

Zachary, yes.. slightly different. Consider the case where you installed a number of packages into your environment and the "new" incarnation rolled out. If during the "upgrade/update" process, your previous environment wasn't updated as well... but backed up... what is one to do.

Being a "hard drive half full, rather than half empty " kind of person, I usually use that opportunity to completely uninstall all vestiges of Arc-Anything, download the *.exe to a folder, run it so I have the *cab and *.msi file (in case I need to reinstall at some point) and then install the "new" version from scratch. This gives me the opportunity to decide whether I really need package X.

Sadly, for many, they don't have control over their own destiny since their computers are controlled by policy at work... they are left to 'clone'.

There are ways to simplify the process, but I think the documentation or builtin tools should be the ones to tell you that... not me.

Since I control my own machine and its destiny, I just conda install into the environment that came with ArcGIS Pro. I, (nor those that I deal with) have had any issues.

ZacharyHart

Dan, thanks as always.

So I guess this is the norm now? I haven't upgraded since the first version where cloning the default env was mandatory so I was thinking there was a bug or something. So I guess the inconvenience is the expected behavior here. Wonderful!

I had previously read all your help guides regarding cloning 'fun' but this seemed like it was perhaps something different.

DanPatterson_Retired

There is definitely no documentation in the help files and your previous environment was just archived.

It is either … a pain …. or, as I prefer to look at it … a fresh start ….

I have flagged a couple of help topics, for their lack of concrete, easy to follow steps without the use of including yaml-speak, pip-speak, clone-free etc.

There are still people out there that do 'analysis' and will require other packages for their work. Perhaps with the 'lock-down' and 'clone' requirements (for those without full control over their computers), simple easy steps to 'migrate' elements from a previous environment to the latest version of pro would be useful

Kory Kramer‌ perhaps you could send this to the documentation team for improvements.

This is gis analyst's equivalent of a web developer's defective widget

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

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