As much as possible this is a cross OS platform question
After I have created and sourced a python virtual environment when I encounter pip install errors like
pip install tensorflow
...
Downloading protobuf-4.23.4-cp37-abi3-manylinux2014_x86_64.whl (304 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 304.5/304.5 kB 3.4 MB/s eta 0:00:00
Installing collected packages: protobuf
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
streamlit 1.12.0 requires protobuf<4,>=3.12, but you have protobuf 4.23.4 which is incompatible.
then outside of this python virt env I see I have streamlit installed as shown by issuing
pip list|grep streamlit
streamlit 1.12.0
naturally I can remove this pip package using
pip uninstall streamlit
I do not care about breaking anything I have installed dependent on streamlit or similar yet I want to avoid breaking other folks python applications/tools/etc
How tight is the referential integrity of system installed python applications regarding pip packages?
UPDATE
my guess is below should show dependencies on package in question
pkg=streamlit
grep ^Required-by <(pip show $pkg)
so if nothing is Required-by I should be free to uninstall offending package ... or no
I do not set env var PYTHONPATH
How tight is the referential integrity of system installed python applications regarding pip packages?
Not tight enough to provide concrete assurances. While the actions taken by pip for any given software installation action will attempt to honor the dependency chain for the software being installed at that time, later installation/uninstallation actions don't concern themselves with whether they break the dependency chains of other software not named in that specific operation.
There are toolchains that provide stronger guarantees -- I'm personally quite a fan of Nix, which when building a Python environment assembles it from hash-addressed entries in a read-only store, which can only be removed from that store when no references to them remain -- but you don't get that from pip alone even within a single environment being managed by pip, much less when there are multiple (system and user) environments overlayed into a single PYTHONPATH being managed independently of each other.