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

GlitchyDot

GlitchyDot

I see FreeBSD already rolled out Python 3.12 , how quickly modules are build for it ? like py-cffi, py-cairocffi they are all 3.11 and will be there 311 versions or once 312 build - 311 will be removed ?
 
I can't talk about build times but it shouldn't take too long. I don't think we are going to kick out 3.11 as soon as 3.12 is released.
 
Many, but not all, python ports have different flavors with different Python versions. Not always possible though.

But if you build your own repository (or build from ports) you can set your own defaults; DEFAULT_VERSIONS += python=3.12 will build everything based on Python 3.12.
 
SirDice said:
Many, but not all, python ports have different flavors with different Python versions. Not always possible though.

But if you build your own repository (or build from ports) you can set your own defaults; DEFAULT_VERSIONS += python=3.12 will build everything based on Python 3.12.
Click to expand...
Where should i set it and how ? Its in Makefile of actual package ?
 
I have python 3.12 i need to build py-cffi port, i go there, i run: env "DEFAULT_VERSIONS += python=3.12" make install clean - but it still builds for 3.11
 
AFAIK you set it in the /etc/make.conf for direct build in the OS, or in your podriere /usr/local/etc/poudriere.d/make.conf. That should (please, someone correct me if I'm wrong) override PYTHON_DEFAULT?= 3.11 from bsd.default-versions.mk
 
astyle said:
Any chances this shakes out before the December release of FreeBSD 15?
Click to expand...
Not sure it's possible or not.
But if you REALLY want it, file a bug with requiring exp-run JUST NOW!
(I wouldn't, as I hate Python as commented below.)


Some details why I state it such a radical way.

Upgrading default Python has too huge an impacts throuout the whole ports tree. So it should require EXPLICIT approval by portmgr (and to include into 15.0-Release, if I understand correctly, EXPLICIT approval by Release Engineering Team [possibly with Secteam]).

And for the approval, if I recall correctly, at least one exp-run (EXPerimental RUN throughout all ports) and fixing exposed build issues (hopefully, additional test on daily use by each maintainers and fixes if needed) is mandatory. Maybe some more cycles would be needed, mean, taking a bunch of times and hastles.

For minor (point) upgrades from Python 3.11.x to 3.11.x+1, it would go smoothly like in PR 281379 and PR 287313, but not assured for 3.11.y to 3.12.z.

And to make sure it to be included in 15.0-Release, it must be in upcoming new quarterly, 2025Q4, as *-Release default to quarterly rather than latest.
More, 2025Q4 should be branched at early October. Just 2 days remains at earliest!


It was a major upgrade, but Python devs did a CRIME on upgrading from 2.x to 3.y, BREAKING LANGUAGE ITSELF! So I can't trust Python upgrades from the point of view with backward compatibilities.

Python should have been renamed at the point. If so, I don't call the change as CRIME, because it's already a different language that looks like Python.

Look at C! Even recent LLVM/Clang can compile ancient K&R syntax, although specific command line option is needed!
This is how programming languages SHALL be.
And to assure it, programming languages needs de-jure standards.
 
T-Aoki said:
It was a major upgrade, but Python devs did a CRIME on upgrading from 2.x to 3.y, BREAKING LANGUAGE ITSELF! So I can't trust Python upgrades from the point of view with backward compatibilities.
Click to expand...
Breaking compatibility between v2 and v3 was intentional, not accidental. No such break would occur going from v3.11 to v3.12. One should always test, of course. And note that python stable version is at 3.13.7, with 3.14 to be released in a week or so.
 
bakul said:
Breaking compatibility between v2 and v3 was intentional, not accidental.
Click to expand...
If it was an accident, I shouldn't have used the too evil term, CRIMINAL.
I used the term because it was intentional.
If they forked and restarted as different language that looks like Python, I shoudn't have used the term, too, even if Python (pre-3.0) is abandoned.
(Cannot blame for abandoning hard to keep project as volunteers.)

No backward compatibilities SHALL be broken until it is called as the same language of different version. That's my point. Programming languages are quite exceptional in backward compatibilities.

Codes written in any programming languages should not be forced rewritten unless any other reason to do so exists.

Providing compilers / interpreters / translators for old syntax with new codebase in pararrel with new-version only ones are OK if the same upstream provides and maintains all of them. I consider it the same as compiler options to switch language versions. Sane.

The only acceptable reason to drop old syntaxes for me is when the syntax (language spec) itself turned out to be fatally vulnerable without good enough reason (like the existence of pointers in C for low level programming) and unfixable on implementations.
 
T-Aoki said:
No backward compatibilities SHALL be broken until it is called as the same language of different version.
Click to expand...
That’s a sane thing to want but we have no real control over what language designers do. There was enough blowback that such breakage is unlikely to happen again in python.

My point was there is no intentionally incompatible change when the minor version changes and upgrades should be relatively straight forward.
 
docs.python.org

What’s New In Python 3.12

Editor, Adam Turner,. This article explains the new features in Python 3.12, compared to 3.11. Python 3.12 was released on October 2, 2023. For full details, see the changelog. Summary – Release hi...
docs.python.org docs.python.org
Code: 
Important deprecations, removals or restrictions:
PEP 623: Remove wstr from Unicode objects in Python’s C API, reducing the size of every str object by at least 8 bytes.
PEP 632: Remove the distutils package.
...

Other Language Changes
The parser now raises SyntaxError when parsing source code containing null bytes. 
...
They said that it was difficult when they changed the default from 3.9 to 3.11, skipping 3.10, so from now on they will change things one by one.
 
T-Aoki said:
If it was an accident, I shouldn't have used the too evil term, CRIMINAL.
I used the term because it was intentional.
Click to expand...
That is a matter of opinion. I think the change from Python 2 to 3 was the right thing to do. Obviously, the details of some of the changes can be argued (was the string -> unicode design optimal?), but overall, it is a good thing to deprecate old mechanisms. The change was intended to have a 10 year (!) compatibility period during which Python 2 syntax was supported; that period ended up being significantly longer.

What is the alternative? A language that tries to support a lot of old, obsolete, and nearly broken stuff, and tries to keep it compatible with new and better mechanisms, which eventually prevents progress. C and C++ are perfect examples of languages that have backed themselves into the backwards compatibility corner.

And I don't care what they call the new language; in practical use, it was always referred to as python3.
 
Note that if a module builds on FreeBSD unpatched, you can use it easily with devel/uv. uv will build it for you on first use and cache the build for subsequent uses.
Code: 
> doas pkg install -q python312 uv
The most recent versions of packages are already installed

> cat cffi_test.py
from cffi import FFI

ffi = FFI()
ffi.cdef("""
    int printf(const char *format, ...);
""")
C = ffi.dlopen(None)
arg = ffi.new("char[]", b"world")
C.printf(b"hi there, %s.\n", arg)

> command time uv run --with cffi --python 3.12 cffi_test.py
      Built cffi==2.0.0
Installed 2 packages in 0.91ms
hi there, world.
        4.17 real         2.32 user         0.28 sys

> command time uv run --with cffi --python 3.12 cffi_test.py
hi there, world.
        0.06 real         0.04 user         0.02 sys
 
dbohdan said:
Note that if a module builds on FreeBSD unpatched, you can use it easily with devel/uv. uv will build it for you on first use and cache the build for subsequent uses.
Code: 
> doas pkg install -q python312 uv
The most recent versions of packages are already installed

> cat cffi_test.py
from cffi import FFI

ffi = FFI()
ffi.cdef("""
    int printf(const char *format, ...);
""")
C = ffi.dlopen(None)
arg = ffi.new("char[]", b"world")
C.printf(b"hi there, %s.\n", arg)

> command time uv run --with cffi --python 3.12 cffi_test.py
      Built cffi==2.0.0
Installed 2 packages in 0.91ms
hi there, world.
        4.17 real         2.32 user         0.28 sys

> command time uv run --with cffi --python 3.12 cffi_test.py
hi there, world.
        0.06 real         0.04 user         0.02 sys
Click to expand...
I could but i wont as then i have to start my WM inside virtual environment and i dont want.

bakul said:
Put DEFAULT_VERSIONS+= PYTHON=3.12 in /etc/make.conf
.
Click to expand...
I dont have make.conf and if i make one , is it ok to have just only one line in it without anything else or its not advised ?
 
GlitchyDot said:
I dont have make.conf and if i make one , is it ok to have just only one line in it without anything else or its not advised ?
Click to expand...
Yes. But note that it may bite you in future, when the default python moves to 3.13 or higher (when you will have to remember to delete that line or change it to something newer). Basically for a long time Unix has been a beautiful idea wrapped in layers and layers of such duct tape.
 
That biting is exactly why I didn't give permission to release that animal:
1759610096079.png
 
You must log in or register to reply here.
Back
Top