Indeed it does, but it’s a less than ideal “fix” for what can be several less than ideal issues.
If you follow official recommendations you shouldn’t use pip to install packages when you have a distro package manager in use, if at all avoidable. Begs the question why is PIP in the distro repositories? (rhetorical question, I know it’s to install and manage packages that are not available in the distro repo, so it is recognised there is a real need to use both).
You should never update PIP via PIP if it was installed via a distro package manager, so why is the function not disabled or something when installed via such a route?
Regular PIP installs on a per user basis so until we crack using other users rather than running everything as pi, using any python package installed via PIP could be problematic, on that note putting “sudo” at the beginning of pretty much every line in the OEM scripts sort of undermines any intention of using users and sudo (and therefore PIP) correctly.
It is recommended that everything python is installed and run in virtualenvs (venv in Py3) but I do not see that in widespread practice anywhere, not just OEM.
I read somewhere in one of the many PIP(3) guides “you should never use sudo when installing from trusted sources” which make little sense if a source is trusted of course you can use sudo if that works for you, the source is “trusted”!!! Maybe a typo but I would agree you should be very wary of using sudo when installing from any untrusted sources such as going direct to Mosquitto repos for example, but you won’t get far trying to install the mosquitto package without sudo regardless of where you are sourcing it. So you should always be cautious of arbitrary code being run as root when installing anything from anywhere, but there are genuine reasons for using sudo, eg when installing a python package vis pip globally for all users.
I’m not saying it’s right! I’m saying it works when all else is less than ideal.