ArcGIS Pro3.3 cannot import third-party libraries located at "\AppData\Roaming\Python\Python311\site-packages"

[圈圈]

Pro3.3 and Pro3.4都不能在自带的Python窗口内import安装在 "\AppData\Roaming\Python\Python311\site-packages"里的Python第三方库，必须将Python第三方库安装在"C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\Lib\site-packages"内才能在自带的Python窗口内import。这是Pro的功能变化还是bug呢？

Neither Pro3.3 nor Pro3.4 can import third-party Python libraries installed in "\AppData\Roaming\Python\Python311\site-packages" into the built-in Python window. Python third-party libraries must be installed in "C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\Lib\site-packages" to import in the built-in Python window. Is this a feature change or a bug in Pro?

[DanPatterson]

can you append or extend using sys.path?

My IDE allows for adding other locations to look for user modules, I haven't experimented with the builtin python window or a ArcGIS Pro notebook

[圈圈]

Yes, it is also possible to import third-party libraries in VS Code, but the built-in Python Windows and custom toolboxes cannot import.

[圈圈]

Yes, the Python built-in window import problem can be solved by adding the destination path to sys.path, but it does not work after restarting ArcGIS.

[圈圈]

For scripting tools, I have to write sys.path into the Python script for the tools to work properly.

[Luke_Pinner]

I assume it's intended behaviour as the point of conda/venv/etc python environments is to not clash with the system python.  If you only have one python, then I can see your issue, but I have many and I definitely do not want them accessing libraries in that user site packages dir.

If you want to add additional libraries, the workflow is to clone your arcgispro-py3 environment and use conda or the ArcGIS Python package manger to install those libraries into the clone.

[圈圈]

Yes, I only have one Python environment, which comes with ArcGIS Pro. I seem to have found a solution, which is to have to start cmd with administrator privileges and pip to install third-party libraries. The third-party library will then be installed in "C:\Program. Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\Lib\site-packages" instead of "\AppData\Roaming\Python\Python311\site-packages". This allows you to import in the built-in Python window.

[DanPatterson]

Package Manager—ArcGIS Pro | Documentation

you can create any environment you want but the issue really depends on whether you want arcpy (hence arcgisscripting) or the arcgis module to work in that environment.  Also, the version of python is pinned to work with arcpy (currently python 3.11.x).

esri cautions about using pip to install packages if there is an equivalent version from conda channels

Package Manager—ArcGIS Pro | Documentation

This provides a list of third party libraries that you can install if they already aren't

Available third-party Python libraries—ArcGIS Pro | Documentation

so check it first since your package may be on esri's channel.

From within conda, install from the 'defaults' channel first before trying 'conda-forge', and pip last.

If you want to create your own environment, you don't need to clone if you don't want to work with/or need arcpy or tools from arctoolbox (for example I currently run python 3.12, numpy 2.2.2 etc separately from the  arcgispro-py3 environment)

[圈圈]

Thank you for your reply. I have read all the linked pages inserted in your reply and benefited a lot from them.

However, this does not solve my problem.

As a secondary developer of ArcGIS, ArcPy is a necessary python library, and other third-party Python libraries may also be used, and some libraries are not available in conda (such as python-docx), so I often use pip installation. This is also a habit I inherited from ArcMap.

Since the toolkits I make are often used by other non-developers, I can't just clone the Python environment for my own use. When other people use the toolkit, my tool automatically installs the Python third-party libraries they need.

In both ArcMap and ArcGIS Pro3.0 versions, my tools were able to automatically install and import Python third-party libraries for others when they were running. But to Pro3.3, the situation has changed, the specific change now Python third-party library installed successfully but can not import, resulting in tool failure. Later I found out the reason, which is that as mentioned before, neither Pro3.3 nor Pro3.4 can import Python third-party libraries installed in "\AppData\Roaming\Python\Python311\site-packages", while Pro3.0 can.

I understand what you are saying and do not recommend modifying Pro's default Python environment. I think Pro3.0 is doing a great job, Because it automatically installs Python third-party libraries in "\AppData\Roaming\Python\Python311\site-packages" instead of "C:\Program. Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\Lib\site-packages" and import smoothly.

While Pro3.3 installs Python third-party libraries in "\AppData\Roaming\Python\Python311\site-packages", but can not import smoothly, the solution is to use administrator permissions for pip installation. But then Python third-party libraries are installed in "C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\Lib\site-packages", This runs counter to Esri's own statement that it "does not recommend modifying Pro's default Python environment."

I can't just clone the Python environment for my own use, because as I said before, the toolkit I make often needs to be used by other non-developers, if my user is using Pro3.3 version, I can only install Python third-party libraries in the Pro3.3 default Python environment.

So I have to think that Pro3.3 has taken a step back in terms of installing Python third-party libraries. This is because it cannot import Python third-party libraries in "\AppData\Roaming\Python\Python311\site-packages", even though this Python third-party library is installed by itself via pip. I even suspect it's a bug.

If my ideas are biased, or if you have a better idea, please do let me know. thank you.