You shouldn’t be using the system-provided Python for anything except system-wide tools that can be packaged and marked dependent on the system Python package (and any Python packages which are packaged as system packages - don’t use “pip install” system-wide). The system-provided Python is mostly there to support system packages/tools that happen to be written in Python.
Stand-alone applications should use pyenv/venv because you can’t guarantee which version of Python is the system-wide one (and you don’t necessarily want to tie your app to the distro’s release schedule). Dependencies should always be in a venv as to not interfere with the system-wide ones or other applications.
If the removal of Python from distro repos breaks your things then it’s a wake up call and you’ve been doing it wrong the whole time. Fortunately it’s an easy fix.
> You shouldn’t be using the system-provided Python for anything except system-wide tools
That does not sound like a user friendly programming language.
The version compatibility of Python is a joke and has been after 2.7 to 3 to. Which is the main reason I don't use Python for anything but bash-like scripts.
One major problem is that some version of Python was supplied with most Linux/Unix distributions - this allowed people to get started without thinking about this problem and then end up too deep in the hole by the time they realise.
Other languages or OSes that don't have their interpreter bundled forced you to think about the problem from the start and build a way to ship a stable version of the runtime with your application.
Python, as a server-side programming language is not too bad. You can standardise on a version and bundle that interpreter version with your application itself in whatever artefact you produce (whether a Docker container, tarball with Python binaries + source or entire VM image with the right Python version installed).
Desktop distribution is a pain, but that's not limited to Python; any language that can't compile to a native binary will have this problem - even Java, despite having much better backwards compatibility, still isn't prefect and sometimes requires an older JRE to be installed on your target machine.
As a matter of practicality I agree but for one not everyone knows this and for another distros like debian don't support what you are saying. We are resorting to pyenv because distros refuse to maintain different application specific python environments. You can pin python versions and deps per package if needed.
Stand-alone applications should use pyenv/venv because you can’t guarantee which version of Python is the system-wide one (and you don’t necessarily want to tie your app to the distro’s release schedule). Dependencies should always be in a venv as to not interfere with the system-wide ones or other applications.
If the removal of Python from distro repos breaks your things then it’s a wake up call and you’ve been doing it wrong the whole time. Fortunately it’s an easy fix.