I have an issue with arcgis-py3 clones.
I just created a clone through the Python Command Prompt (through AGPs UI never worked for me!), and swapped the default environment to the newly created one.
Then I made the attempt to update the arcgis package.
conda update arcgis
The result on a fresh environment is
I went then to jupyterlab, trying to install jupyterlab-manager, which requires NodeJS. Hence, back to the command prompt and
conda install nodejs
The result is of course the same. The inconsistency persists.
How can I avoid the inconsistencies, except from not trying to update or install anything?
I am on ArcGIS Pro 2.9.0
some of the packages can't be updated if they come from the Esri conda channel. Either because they are pinned or break dependencies in the chain.
you try
condal install nodejs --no-pin
and it will search the esri and defaults channels of Anaconda main packages if there is an update available
Hi @DanPatterson,
I am aware that the arcpy package cannot be updated, and did not try. I also did not continue to update the arcgis package when receiving the message.
However, I had a look for the pinned file, at much to my surprise, there is non in the conda-meta directory.
If there is no pinned file, then where does the system takes the information from that
a) something is pinned, and
b) --no-pin will have an effect?
In my base environment
C:\__your_install_folder__\bin\Python\envs\arcgispro-py3\conda-meta
C:\__your_install_folder__\bin\Python\res
in a clone
C:\Users\__you__\AppData\Local\ESRI\conda\envs\pro_3\conda-meta
In a pinch, I have even resorted to moving the existing pinned file and replacing it with an empty one.
It might break something, but reinstalling Pro takes less time than trying to track down a source of a conda issue.
Specifying -c defaults sometimes works when installing or updating packages but I have given up on pip and installing anything from conda-forge because of conflicts.
I usually install packages in the base environment (for example Spyder and other packages) since I have full admin rights to my machine and a
conda install --revisions (desired revision # here)
or Pro reinstall usually fixes any issues with an environment gone wrong.
yes, in the res directory of the base environment, there is a pinned file. There is also one in the conda-meta environment.
Looks to me like conda create --clone arcgispro-py3 --name NAME does not create a clone including the pinned file.
To a certain degree that is also what the user wants. I create the clone to be able to install what I need and want. At the same time, the absence of a pinned file, containing at least the packages that can't be updated is rather creating problems, than providing solutions.
I didn't check the order of channels, and would assume the esri channel comes before the conda-forge, but setting -c pointing at conda-forge gave me the same message about the inconsistency.
@DanPatterson wrote:I usually install packages in the base environment (for example Spyder and other packages) since I have full admin rights to my machine and a
conda install --revisions (desired revision # here)
How do you install something in your base environment? Do you simply use the command line and --no-pin?
The pinned files for the base environment are up to the neck full with all the base packages...
I should have indicated that cloning through the Package Manager produced the pinned file in my example
I use the command line usually with --no-pin If it doesn't cause any conflicts with what Pro requires, there is usually no problem.
The "pinned" file is just a text file, as you know, which you can copy (for backup purposes of course), if can be duplicated, and moved, you can create a new version of it if you wanted. You can also do this with the conda-arc file and the package .json files that you have probably discovered. The details would probably make a good blog article (python blog) but then people with less familiarity with conda, pinned and json package descriptions might try to do something and get into problems. For those with more experience, I recommend experimenting and using "..... install --revisions ... or a complete reinstall of Pro if needed. I need not say more
Did you ever figure out a solution for this? I have the same issue off a fresh 2.9 install and almost exactly the same packages causing the mismatch.