Why are there three pythons in the system?

Installed packages to be UPGRADED:
python36: 3.6.13 -> 3.6.15
python37: 3.7.10_1 -> 3.7.12
python38: 3.8.10 -> 3.8.12

Number of packages to be upgraded: 3
 
Why are there three pythons in the system?

Sometimes they're dependencies.

Here (without expressing the dependencies):

Code:
root@mowa219-gjp4-8570p-freebsd:~ # pkg info -x python3
python3-3_3
python37-3.7.12
python38-3.8.12
python39-3.9.7
root@mowa219-gjp4-8570p-freebsd:~ # pkg autoremove

harfbuzz-2.9.1 is locked and may not be modified

harfbuzz-icu-2.9.1 is locked and may not be modified
Checking integrity... done (0 conflicting)
Nothing to do.
root@mowa219-gjp4-8570p-freebsd:~ #
 
These really need to be put in subdirectories it's a nuisance having so many with minor changes.
They are. That's why you can install multiple different versions without conflicting with each other.

But in the OP's case I suspect it's just a result of only running pkg upgrade and not running pkg autoremove after it. The default Python moved from 3.6 to 3.7 to 3.8, if you don't clean up after an upgrade you're going to be left with a bunch of unnecessary dependencies installed.
 
Burmese and reticulated. I do not know what is the third type of python.

But this turned up in front of my house:

1633010955683.png
 
At least it's Python3... KDE is still kind of stuck with Python 2.7, in spite of efforts to move away. Part of the problem is Qt 5.15 modules (Stuck with them until the KDE project makes the move to Qt 6, which is not happening until Qt 6 reaches feature parity with Qt 5.15).
 
This is a general, inherent problem of scripting languages.
No. This is simply poor engineering practice. Languages like Perl and Lua very rarely have serious backwards compatibility problems. The Python Steering Committee learned the wrong lesson from the Python 2 -> 3 fiasco, and has been introducing breaking changes in every dot-release. It seems it has finally caught up with them if you read the PEP I linked in my last post.

See how Perl handled a potentially dramatic change:

TL;DR This is a Python problem, not a Freebsd problem.
 
To avoid problems i have in make.conf
Code:
DEFAULT_VERSIONS+=python=3.8
DEFAULT_VERSIONS+=python3=3.8
And in blacklist
Code:
lang/python2
lang/python27
lang/python36
lang/python37
 
To avoid problems i have in make.conf
Code:
DEFAULT_VERSIONS+=python=3.8
DEFAULT_VERSIONS+=python3=3.8
And in blacklist
Code:
lang/python2
lang/python27
lang/python36
lang/python37
This is nice, but that does add to the list of admin chores to update the default version of Python from time to time - in the correct place.
 
The world is not perfect.
In make.conf I specify the default versions for ssl,llvm,gcc,lua,perl,python,ruby,pgsql,mysql,php,tcltk.
And I hope "UPDATING" is clear enough to inform when i need to change ...
 
Back
Top