Accepted Solutions
Simon.. when you go to the first install, you are asked 'install for all users' or something like that. I don't, … my machine... one user... so then you get to navigate to a folder where you want to install it (I just made and use C:\ArcGIS
So the executable is located in :
C:\ArcGIS\bin\ArcGISPro.exe
- arcpy starts in
C:\ArcGIS\Resources\ArcPy\arcpy (then you have to follow the import paths from the __ini__ files
- python is in several envs
C:\ArcGIS\bin\Python\envs\arcgispro-py3
C:\ArcGIS\bin\Python\envs\dan
- arcgisscripting gets installed in the lib folders of
C:\ArcGIS\bin\Python\envs\arcgispro-py3\Lib\site-packages
C:\ArcGIS\bin\Python\envs\dan\Lib\site-packages
The rest of the packages that I install or update are all done in my env.
I am not enamoured with the extra baggage with the clone, but apparently it guarantees 'you the user' and environment that will work if things go bad.
My experience is to view a bad install as an opportunity to reinforce my software installation skills so they don't get rusty 
Couple of questions:
Following your suggestion, I used a simpler install path and cloned the arcgispro-py3, with addresses as follows:
C:\Arc_Pro\bin\Python\envs\arcgispro-py3
C:\Arc_Pro\bin\Python\envs\arcpro233
I did all updates and installation of Spyder using Conda and everything went fine. A few days later, I went into ArcGis Pro Python Package Manager, to see how things worked from there. Both environments show up, but both of them are locked down; I cannot install or update packages in my clone (arcpro233) in ArcGIS Pro, the update and install buttons are grayed out. 
Do you manage the environment solely from Conda, or is there something wrong with my install and I should be able to use the Python Package Manager?
I cloned arcpro233 and let Esri choose the location in AppData to see if I could update that in the Python Package Manager. It said it had 39 updates (why, I don't know because I had just updated arcpro233 in Conda). I clicked Update All, when done, it still claimed to have 39 updates. I then went to Conda and did "conda update --all". It said "All requested packages already installed." So, does the Python Package Manager show updates for all packages in that environment, whether or not the updated package can be used in that environment? So when I try to update, it doesn't install the updated packages because they would mess up the environment?
Cheryl... I do everything from conda to ensure that I have the right environment selected. Ignore the updates available in the Package Manager, it doesn't appear to 'see' what conda 'knows'
Now... having said that. If you have full rights to your computer (ie not muzzled by work limitations'), I no longer 'clone', hence my other blog
/blogs/dan_patterson/2018/12/28/clone
What I do when a new version of ArcGIS Pro comes out is look at it as an opportunity to freshen up my computer.
I remove all vestiges of Arc* from my machine (keeping a copy of 'pinned' and 'environments.yaml'). Spyder keeps its state in your users folder. But I do remove anything Arc* related from c:\Users....
- I download the *.exe to disk into a know folder, where I keep the previous 2 version of Pro.
- I execute the *.exe as administrator in that folder which will yield a *.cab and a *.msi file. I run the *.msi and install Pro in C:\arc_pro (or C:\arcpro... whatever)
- I crank up conda and you will be in the default ArcGIS environment
C:\arc_pro\bin\Python\envs\arcgispro-py3>
- I always do a 'test' install of any package by doing a 'dry-run
C:\arc_pro\bin\Python\envs\arcgispro-py3>conda install spyder --dry-run
- Sometimes esri has 'pinned' a package that I want to upgrade. For instance in one of the recent versions, numpy was pinned at version 1.15.x, I wanted 1.16, soooo
C:\arc_pro\bin\Python\envs\arcgispro-py3>conda update numpy --no-pin --dry-run
- Living on the edge, I will proceed to...
C:\arc_pro\bin\Python\envs\arcgispro-py3>conda update numpy --no-pin
- I will list the packages that it will upgrade, downgrade and install where applicable. Copy that list! to Notepad++ or Notepad so you have a record.
- I test to make sure spyder works. I then begin upgrading packages as I need them, typically esri runs a version or more behind in numpy, scipy and some of the other packages in the sci stack.
Now if things go realllll bad, you have some options.
- Roll back an install. First you need to get a list of revisions you have made to track down which something went south
C:\arc_pro\bin\Python\envs\arcgispro-py3> conda list --revisions
That will give you a listing of all the revisions you have made and you can determine where the bad install or improper package dependency wasn't good.
This is usually to do with a particular package depending on another package. Recently, a 'bug' in one package that I updated to the most recent version (Sphinx)
caused issues with numpy doc strings. So I had to rollback the update.
C:\arc_pro\bin\Python\envs\arcgispro-py3> conda install --revision [revision number]
Where revision number will be an integer (no brackets either)
Now... for practice and if you really muddle everything up completely, you just go back delete everything except the *.exe (for safekeeping) and rerun the *.msi and start again.
I have followed this procedure and we even create an 'image' without a clone which we deploy to our network labs since we don't want students cloning stuff (we wipe and
reimage the computers regularly to clean up after the 'clever' ones .
After this long missive. If you do not have control over your computer, you will have to get the IT person a chair to sit beside you to go through this. When they feel comfortable that the world won't come to an end, they might agree to deploy an image suitable to all and you can skip the cloning all together. The purpose of cloning was/is to ensure that you have a useable Pro setup if the clone cause issues. hmmmm, cleaning up and running the *.msi only takes a coffee in time, so weighing your options is up to you.
On a final note... If I want to try a radical deployment full of totally untested fun stuff (think machine learning, AI, numba and other unknown packages). I do all that stuff on a separate machine because computers are way cheaper than my time.
Have fun and good luck
Cheryl, as for --dry-run ...I use it largely to see whether a certain package will be downgraded when I am upgrading or installing another package. For instance, when the 'arcgis 1.6 module was around, I had already upgraded to 1.6.1 and I wanted to upgrade numpy to 1.16.3. The --dry-run indicated that a rollback was in order, so I did a --no-pin --dry-run and found out that esri's 'pinned' file could be overridden without any roll back, so i just did a …
C:\arc_pro\bin\Python\envs\arcgispro-py3>conda update numpy --no-pin
I lived to tell this tale
I am now on ArcGIS Pro 2.4 Beta 2 and done subsequent upgrades and things are working well. Esri isn't really advertising that fact, but I guess they realize that there are indeed valid situations where cloning isn't needed or desirable.
Picture teaching labs with 50+ computers. The base environment is installed at the beginning of term. Some package has an upgrade that fixes a 'bug' or adds 'new functionality'. Now picture telling the students to 'clone' the environment and do the upgrade... you now have two large installations. Next day, different class... clone again by different people... now 3 installations... Student day one comes into the lab sits at a different computer... clone again … and so on. What we do is install one 'computer image', if an update needs to be done, it is upgraded, then blasted out to all the machines. No cloning, no wasted space and no problems. Of course, we have one machine for image testing before we deploy to the universe
