Python We have Python 3.12 already in FreeBSD - how long it takes to build modules for it ?

bakul said:
My point was there is no intentionally incompatible change when the minor version changes and upgrades should be relatively straight forward.
Click to expand...
That has certainly not been my experience. Minor versions often introduce incompatibilities. Python introduces new minors every year, and only supports them for two years. Writing stuff in Python nowadays is dooming yourself to a death of a thousand cuts "fixing" administrivia in your code base.

ralphbsz said:
What is the alternative?
Click to expand...
Maybe something like this:
en.wikipedia.org

Raku (programming language) - Wikipedia

en.wikipedia.org en.wikipedia.org
 
Jose said:
That has certainly not been my experience. Minor versions often introduce incompatibilities. Python introduces new minors every year, and only supports them for two years. Writing stuff in Python nowadays is dooming yourself to a death of a thousand cuts "fixing" administrivia in your code base.
Click to expand...
I actually consider this to be a good thing. Python explicitly deprecates obsolete features and libraries; it gives you a long warning period (the transition from 2 to 3 was advertised for 20 years, and things like the gci library get multiple years of being kept on life support while obsolescent). That keeps the officially supported library smaller and better maintained, and allows it to slowly move to better designs and new features. It does indeed take a little bit of regular maintenance, but I think that's a much better investment than relying on antique features, which then bring in massive technical debt.
 
Charlie_ said:
There seems to be resistance from people who want the default to be 3.13.
lang/python31[012]: deprecate 2026-03-31
Revert "lang/python31[012]: deprecate 2026-03-31"
Click to expand...
For ports affecting too many ports on upgrading, intensive discussion on maintainer team (for python, there's python@) before deprecating / switching default would be strongly wanted to avoid such a commit/revert war.
 
T-Aoki said:
For ports affecting too many ports on upgrading, intensive discussion on maintainer team (for python, there's python@) before deprecating / switching default would be strongly wanted to avoid such a commit/revert war.
Click to expand...
Someone needs to intervene.
"Reapply "lang/python31[012]: deprecate 2026-03-31"
Edit: https://cgit.freebsd.org/ports/commit/?id=ac6809aadf8da7bf3288fbfcadde21f253cc20b6
Revert "Reapply "lang/python31[012]: deprecate 2026-03-31""
 
My experience with Python on FreeBSD is underwhelming. I can’t rely on uv. I’ve tested it rigorously.

My go to for Python build environments is Pixi but it is not supported yet sadly
 
I think Python project (upstream, not for ports) should fixup anything released to be immutal (in syntax and functions) and allow simple additions only. This way, backward compatibilities are assured and no more exp-run and this kind of mis-communications cannot happen anymore.

ISO/IEC should strictly define the language and disallow changes other than simple addition unless the change is mandatory for fixing vulnerabilities.
Python is already too bloatedly used in the wild to "change other than additions".

And changing infrastructure for its ecosystem is quite large a pain.

FYI: At commit 6ee690a735724307a2312b5a655a7e491d1185c4 on main (aka latest) branch of ports tree,
Code: 
% bfs /usr/ports/ -name "py-*" -type d | wc -l
    4933
%
Used sysutils/bfs and omit error messages with regard to permissions in distfiles subdirectory.
There should be more ports written in Python which don't have prefix py-.

Transition of build environment / ecosystem could affect such a non-trivial number of ports, thus, should need quite intensive discussion before deciding to do or not to.
 
Charlie_ said:
There seems to be resistance from people who want the default to be 3.13.
Making sure you're not a bot! lang/python31[012]: deprecate 2026-03-31
Making sure you're not a bot! Revert "lang/python31[012]: deprecate 2026-03-31"
Click to expand...
Actually not easy to follow all the discussions concerning python (default / cython / numpy / commits reverts / security issues...)

I would also prefer 3.13 as the default.
But if it is possible to build important modules for 3.13, then the 3.12 as default version could simply become a "luxury problem"?
I also agree with T-Aoki:
the last commit by Antoine should be considered as the final decision as FreeBSD project
Click to expand...
Much more important is to move forward.
 
I’d like 3.13 to be the default as well

But 1 thing I notice testing newer versions of Python is that under heavy loads it kicks back the compute to an older version of Python on base system.

Does anyone by chance know why
 
What's needed to be concerned would be this Antoine's comment.

And (not me, though, as I dislike any language ignoring backward compatibilities) exp-run (test build of the whole ports tree with patches to be tested) for 3.12 and correlated fixes are already ongoing.

Switching now is just a waste of time and efforts of related developers / maintainers, and starting next exp-run for next switch to 3.13 AFTER the switch to 3.12 with required fixes are completed seems to be far more constructive way.
 
I change the ports default python to 3.14 recently, only firefox-esr cannot be built, but it seems firefox supports 3.14 already. Everything is fine so far. For cython, I have to change the dependency to cython3 for some ports.
 
You must log in or register to reply here.
Back
Top