... all that is needed for the switch is pipoverride="no".
technically pipoverride enforces the use of pypi rather than apt repo. This is useful for new libs that are yet to be published in the Raspbian repo.
It can also serve in emergency cases, where a hot fix need to be pushed but apt repo syncing is deemed likely to delay unacceptable the fix being public. It's preferable not to use though, it should be fine to revert to the OS owned version later but it's a scenario best not abused.
Note that the fetching of the libraries from the apt-repo, specifically Raspbian at this stage is implemented so that it falls back onto Pipit if it can't be fulfilled, for whatever reason (dpkg db damaged, or whatever else might cause that to happen).
The above is also the expected mechanism for any OS other than Raspbian - though I'm yet to delve deep into the finer details that may make the experience as good for user as possible (i.e not appear to have failed).
... all that is needed for the switch is pipoverride="no".
technically pipoverride enforces the use of pypi rather than apt repo. This is useful for new libs that are yet to be published in the Raspbian repo.
It can also serve in emergency cases, where a hot fix need to be pushed but apt repo syncing is deemed likely to delay unacceptable the fix being public. It's preferable not to use though, it should be fine to revert to the OS owned version later but it's a scenario best not abused.
Note that the fetching of the libraries from the apt-repo, specifically Raspbian at this stage is implemented so that it falls back onto Pipit if it can't be fulfilled, for whatever reason (dpkg db damaged, or whatever else might cause that to happen).
The above is also the expected mechanism for any OS other than Raspbian - though I'm yet to delve deep into the finer details that may make the experience as good for user as possible (i.e not appear to have failed).