This question is a follow-up to the question asked here.
I prefer not to live in the conda environment that ships with ArcGIS Pro. In ArcGIS Desktop, I could simply copy a single .pth file to any other Python installation and then import arcpy from consoles and within scripts. At some point, this stopped working in ArcGIS Pro.
An Esri staff member previously indicated that the process of making arcpy accessible in this way would be simplified in ArcGIS Pro 2.1. Is there any update on this topic? Has anyone managed to import arcpy from ArcGIS Pro in this manner?
Solved! Go to Solution.
The specific feature to use an external conda from within the app didn't ship with 2.1, unfortunately. That said, you do have a few options:
1. If you install the program per-user, then UAC will never be invoked, and all of the conda installation will reside inside your AppData directory, and the backstage will install packages to that location.
2. You can create new environments, and use them, from your AppData location, by creating them with Conda. If you run something like `conda create --clone arcgispro-py3 --name my_env` from the command line, it will by default create that new environment in your user profile. You can then use it as you would any other, the only caveat with this approach being that the environment in AppData can't drive Pro itself.
3. You can integrate with an external conda, it just isn't as easy as it should be, and a better approach is being actively worked on.
Cheers,
Shaun
Nothing new beyond what was recommended by Shaun recommended which didn't work for some.
2.1 ships with python 3.6.2 and the Anaconda environment it has is pretty packed and a lot of other stuff can be found on their site even if it is packaged in the esri distribution.
Is there a reason you don't want the package distribution?
Dan Patterson wrote:
Is there a reason you don't want the package distribution?
I'm not at all enamored of the idea of creating and deleting conda environments ad hoc on the C: drive. As a federal employee, write access on system disks is heavily restricted. I've used a freestanding Miniconda installation under my user profile for years precisely to avoid any unforeseen, hard-to-detect bugs resulting from security/admin conflicts with conda or other Python packages.
In fact, after doing some testing on my home computer, I'm not sure if I will be able to create a new environment at all. The Python Package Manger interface seems to activate conda_uac.exe when creating a new environment. Elevated administrative privileges will very likely be needed.
Good points Phil.
Maybe SWalbridge-esristaff might be able to answer.
This is especially important given the number of users that don't have the luxury of being able to have full admin privileges on their computers.
I do like the new ability to clone/delete an environment for quick testing, especially if you don't want to use command line conda.
Maybe this can be addressed now or during the ArcGIS Pro 2.2 Beta (starting soonish(?) )
The specific feature to use an external conda from within the app didn't ship with 2.1, unfortunately. That said, you do have a few options:
1. If you install the program per-user, then UAC will never be invoked, and all of the conda installation will reside inside your AppData directory, and the backstage will install packages to that location.
2. You can create new environments, and use them, from your AppData location, by creating them with Conda. If you run something like `conda create --clone arcgispro-py3 --name my_env` from the command line, it will by default create that new environment in your user profile. You can then use it as you would any other, the only caveat with this approach being that the environment in AppData can't drive Pro itself.
3. You can integrate with an external conda, it just isn't as easy as it should be, and a better approach is being actively worked on.
Cheers,
Shaun
Thanks Shaun. Your reply actually helped me out, and I think my problem is basically solved. In case it's useful to others, here's what I did:
Some notes about this process:
I do look forward to having things more streamlined, but for now this is sufficient.
Thanks again!
********** UPDATE **********
philmorefield wrote:
Thanks Shaun. Your reply actually helped me out, and I think my problem is basically solved.
Once again, I spoke too soon. Everything seemed to be working okay, until I start trying to update packages. The numpy package, for example, wouldn't update past 1.13.x, no matter what. I'm not satisfied with that; others might be.
So I went back to the original post here and gave Shaun's original instructions another try. And it worked. I can import arcpy, update numpy, and do whatever else I need to do. The steps are:
And that's it. So far I've done this on two computers and it seems to be working for both.
Hi Phil, using this approach are also also able to run Jupyter notebook. Can you install other open source libraries such as GDAL, geopandas, cartopy etc also still be able to use arcpy? That is, mix and match arcpy with other open source libraries in the same script.
Bidhyananda Yadav wrote:
Hi Phil, using this approach are also also able to run Jupyter notebook. Can you install other open source libraries such as GDAL, geopandas, cartopy etc also still be able to use arcpy? That is, mix and match arcpy with other open source libraries in the same script.
Yes.
Following the steps I laid out means you will have a standalone Python installation that is independent of ArcGIS Pro, i.e., you won't "break" ArcGIS Pro by installing or updating packages. But, you will be able import arcpy into scripts just like any other Python package. To be fair, I haven't used arcpy in Jupyter yet, but I've done all of my work for years with this type of set up and never had a conflict with arcpy.
Unless Shaun meant ... making it easier ... was in reference to