Remember when I posted how to debug multiple versions of python3? Apparently I ran into another similar issue wherein I cannot get the system python to behave properly. pyenv global system will not work. I was working on a new setup, so my tools haven't kept up, and I haven't added that solution to my automated arsenal just yet, woe to me.
The scenario was, Ubuntu uses 3.12, the newly installed pyenv has none, and I have my old resource files transferred over to my machine. Setting pyenv global system is supposed to call the system python. However, calling pip posts an alarm that it is under an externally managed system. And for some reason, the whereis python3 would call upon a pyenv path to 3.11.
This solution from StackOverflow posts a plugin solution that allows Pyenv to register Python3 outside those managed by Pyenv, and allow Pyenv to manage it. Using this plugin will allow you to forcibly register the system python, renamed as system-itspythonversion. And doing so would allow the system python to behave as intended.
But where is the 3.11 coming from? And why is it being called and causing an error when used in Pyenv?
It was because it was aliased in my resource file. I have to comment it out to fix that weirdness.
This is incredibly painful, personally, and a reminder for those who are very much eager to alias your interpreters. If your interpreter versions are managed by a tool (rvm, pyenv, nvm), using an alias can cause some inconsistent behaviors where the interpreter you have called is not the interpreter you wanted. As much as pyenv have tools to override shell settings, even aliases, aliases can still override the source and context of a command in some cases.
Building a mental model of the many places Python3 can exist on your project is a pain.
There is the distribution python, the project virtualenv python, the pipx python, the pyenv global python, the pyenv local python, the pyenv shell python, the poetry python when its virtualenv is stored in a folder outside the project, the poetry python that is supposed to be stored in the project-level virtualenv, whose settings have to be setup up beforehand. You get my drift.
The solution I posted before, you know, the preexec function that returns which on your command still is useful to catch yourself with this, all of this shit. But at least, if you don't alias your interpreters, you remove another headache to the mix.
I honestly might as well call python3 binaries from their full path. That should make things less painful.