In D53489#1224804, @mikael wrote:

There are 2 version of openssl-probe (openssl-probe-0.1.5/ openssl-probe-0.1.6), only 0.1.6 needs to be patched?

Both patches apply cleanly here.

In D53489#1224730, @mikael wrote:

I'm updating rust to 1.91.0, does it apply to this version ?

@mikael Any objections? This has also been incorporated into devel/uv, upstream patch is in discussion.

In D53433#1224443, @vishwin wrote:

In D53433#1224442, @michaelo wrote:

In D53433#1224438, @vishwin wrote:

USES=distutils is going away because upstream is removing support for this entirely. It had been deprecated for quite some time but they are finally pulling the switch.

I know, this is why I said that with PEP 517 wheels already there, they just need to be in a distinct, explicit place for consumption.

Can you explain why this change needs revision? ATM, I don't see a way to make it even simple than this. Again, I don't expect you do upload anthing to PyPI. It is just a possible usecaes. I am happy if people can host their own indexes with this.

From a meta-/framework perspective, building wheels from USE_PYTHON=distutils (ie direct setup.py invocation) is not reliable unless you don't pass any flags or variables at all. This stems from setuptools themselves continuing to deal with a littany of legacy code and design which is frustrating to rid for modernity and maintenance sakes. Trying to build a binary wheel from built artefacts in this case may result in those artefacts getting wrongly rebuilt. (I had some local modifications where USE_PYTHON=distutils only built binary wheels and eliminated its do-install in favour of the PEP-517 do-install.)

For those ports that still have a setup.py without a corresponding or replacement pyproject.toml that doesn't need to have flags or variables passed into configure or build, PEP-517 already provides that setuptools is implicitly the build backend. Those ports can switch to USE_PYTHON=pep517. For ports that need to pass flags and variables, setuptools still doesn't support config settings passed from a build frontend like devel/py-build.

In D53370#1224466, @john_saltant.com wrote:

Thank you for your contribution.

In D53433#1224457, @arrowd wrote:

In D53433#1224456, @michaelo wrote:

I don't know whether it can be compiled on 13.5 and run older minor versions.

It can't generally. But this is not a problem, because the support window between two consecutive minor releases is usually tight and the official cluster always builds packages on the lowest minor version supported.

In D53433#1224455, @vishwin wrote:

In D53433#1223609, @arrowd wrote:

In D53433#1223585, @michaelo wrote:

Here is the definition: https://packaging.python.org/en/latest/specifications/binary-distribution-format/

There is a notion of a "platform tag" which denotes the platform for which the wheel has been built if it contains native code, by default it does "$(os}_${release}_${arch}". Run " pip debug --verbose" and see for compatible tags. If a wheel has been compiled with 13.5-RELEASE-p5 it won't be consumed by 13.5-RELEASE-p6. "wheel tags --remove --platform-tag=..." renames the file for multiplatform AND modfies the metadata (Tag: ) in WHEEL file. So I am not rebuilding, I am retagging. I first assumed a bug in poudriere: https://github.com/freebsd/poudriere/issues/1277, but then realized otherwise.

Well, to me it is the python part that should be fixed. FreeBSD guarantees ABI compatibility between minor releases, so the tag should look like py310-none-freebsd_13_amd64. This is the same how pkg handles our native packages ABI.

Re-tagging is not necessary as they are already correct. Not every wheel will have specific platform tags, in fact most if not all ports specifying NO_ARCH will have py3-none-any which allows consumption on anything with any implementation/distribution. Patch levels are not part of specific platform tags, only minor releases, like cp312-cp312-freebsd_14_3_release_amd64 (denotes compatibility with CPython >= 3.12 on 14.3-RELEASE amd64), cp37-abi3-freebsd_16_0_current_amd64 (CPython >= 3.7 ABI 3 on -CURRENT amd64). (If we enable building ports under other implementations like lang/rustpython, that's another can of worms entirely…) Note that 3.13 and later have differing ABIs wrt free-threaded mode or not, like cp313-cp313t-freebsd_16_0_current_amd64.

In D53433#1224443, @vishwin wrote:

In D53433#1224442, @michaelo wrote:

In D53433#1224438, @vishwin wrote:

USES=distutils is going away because upstream is removing support for this entirely. It had been deprecated for quite some time but they are finally pulling the switch.

I know, this is why I said that with PEP 517 wheels already there, they just need to be in a distinct, explicit place for consumption.

Can you explain why this change needs revision? ATM, I don't see a way to make it even simple than this. Again, I don't expect you do upload anthing to PyPI. It is just a possible usecaes. I am happy if people can host their own indexes with this.

From a meta-/framework perspective, building wheels from USE_PYTHON=distutils (ie direct setup.py invocation) is not reliable unless you don't pass any flags or variables at all. This stems from setuptools themselves continuing to deal with a littany of legacy code and design which is frustrating to rid for modernity and maintenance sakes. Trying to build a binary wheel from built artefacts in this case may result in those artefacts getting wrongly rebuilt. (I had some local modifications where USE_PYTHON=distutils only built binary wheels and eliminated its do-install in favour of the PEP-517 do-install.)

For those ports that still have a setup.py without a corresponding or replacement pyproject.toml that doesn't need to have flags or variables passed into configure or build, PEP-517 already provides that setuptools is implicitly the build backend. Those ports can switch to USE_PYTHON=pep517. For ports that need to pass flags and variables, setuptools still doesn't support config settings passed from a build frontend like devel/py-build.

In D53433#1224438, @vishwin wrote:

In D53433#1223076, @michaelo wrote:

My ideal longterm goal: The Project hosts canonical poudriere builds and these could produce FreeBSD-specific wheels which could be uploaded to PyPI and would dramatically improve the situation for the Python ecosystem on FreeBSD.

Not happening. We already build artefacts for ports with non-standard flags and such, which are inappropriate to share to PyPI.

In D53433#1224026, @arrowd wrote:

This looks OK to me, but I'm a python hat wearer.

Update range in comment

In D53370#1223953, @john_saltant.com wrote:

Please keep the comment, updating it as appropriate.

Update port

Any opinion or objection?

@sunpoet Any opinion or objection?

@sunpoet Any opinion or objection?

Any opinion or objection?

@sunpoet Any opinion or objection?

@dereks_lifeofadishwasher.com Any opinion or objection?

@mikael Any opinion, objection?

@arrowd I have now simplified the patch to work out of the box. It requires a subsequent patch (already prepared) for ports (seven of them) which overwrite those commands. The collection logic can fully live in poudriere: https://github.com/michael-o/poudriere-python-wheels/pull/1/files#diff-0afccccb8f3a6069f1dad4ec5c98125d10435243f7848807d2bcf65e00e88282R20-R34

Simplify approach by making wheel destination explicit

In D53433#1223613, @arrowd wrote:

In D53433#1223612, @michaelo wrote:

I agree with you, but that you I think require a PEP describing this (e.g., https://peps.python.org/pep-0513/).

While this sounds complex, I think this would be just a several lines of code in a correct place. If you don't want to open a PEP for this (which also shouldn't as complex as manylinux one) we could at least patch this in our Python ports.

After that one needs to modify pip, setuptools, maturin, uv, and likely other code. It isn't straight forward.

Hmm, why so much places should be touched? Everything should start working out of the box when we get Python to use proper tags, no?

In D53433#1223609, @arrowd wrote:

In D53433#1223585, @michaelo wrote:

There is a subtile difference where. The wheels are already there with PEP 517, distutils just requires one more step, but I expect distutils to disappear in the future. So basically either "make wheel" would be a noop or it would move/copy the *.whl to ${WRKDIR}/whl/

All right, if wheels are already generated unconditionally, then this point is resolved.

In D53433#1223564, @arrowd wrote:

In D53433#1223130, @michaelo wrote:

As a plugin, yes?

If it can be completely done via a hook - yes, but not necessary. It might be as well a core feature.

But as long as It is not stable I don't want to have it upstream and constantly break people's stuff unless we mark it as experimental.

This is not a problem - we have poudriere-devel exactly for that.

@arrowd There is one issue with retagging the wheel inside of the jail. Let's say the jail has been updated from 13.5-RELEASE-p5 to 13.5-RELEASE-p7. There is a wheel for package foo. The multiplatform wheel goes only to 13.5-RELEASE-p5. Unless the port is upgraded to a newer version the multiplatform tags will never be updated and for jails running 13.5-RELEASE-p6+ unavailable. This means that I still need to perform the retagging for older wheels, but not for newer ones with a poudriere hook. So at the end it will be duplicate work. I don't know wether this is really smart to do...

In D53433#1223124, @arrowd wrote:

It should be turned into a proper pull request to the Poudriere upstream repo.

In D53433#1223122, @arrowd wrote:

Link your Poudriere changes in there, so it is possible to get an idea how this is going to work overall.

In D53433#1223077, @arrowd wrote:

Then this change alone isn't really enough and I'm not even sure it is a right step forward.

My ideal longterm goal: The Project hosts canonical poudriere builds and these could produce FreeBSD-specific wheels which could be uploaded to PyPI and would dramatically improve the situation for the Python ecosystem on FreeBSD.

In D53433#1223067, @arrowd wrote:

I don't quite get the rationale. Can you provide an example how is it going to be used?

@yuri Thank you for the merge!

In D53370#1220046, @michaelo wrote:

In D53370#1220044, @john_saltant.com wrote:

Does this version build successfully against each version of Python currently in the tree, and against each GSSAPI library?

It does officially support 3.13 and 3.14, therefore I removed the comment. If you consider to limit the Python version it should be in the variable to fail hard and not just a comment. WDYT?

See: https://github.com/pythongssapi/python-gssapi/commit/d792186a8b80e4906773b2d39a9815371ce1499c

Manually merged by @vishwin.

In D53370#1220044, @john_saltant.com wrote:

Does this version build successfully against each version of Python currently in the tree, and against each GSSAPI library?

Already solved with f8bd5c67bbce81cb06b5823ade537c4f0459df55 by @sunpoet

Reset revision

Tested:

[00:02:20] [01] [00:01:13] Finished   devel/py-rpds-py@py311 | py311-rpds-py-0.28.0: Success
[00:02:21] [01] [00:00:00] Building   devel/py-referencing@py311 | py311-referencing-0.36.2
[00:02:37] [01] [00:00:16] Finished   devel/py-referencing@py311 | py311-referencing-0.36.2: Success
[00:02:37] [01] [00:00:00] Building   devel/py-jsonschema-specifications@py311 | py311-jsonschema-specifications-2025.9.1
[00:02:49] [01] [00:00:12] Finished   devel/py-jsonschema-specifications@py311 | py311-jsonschema-specifications-2025.9.1: Success
[00:02:50] [01] [00:00:00] Building   devel/py-jsonschema@py311 | py311-jsonschema-4.25.1
[00:03:03] [01] [00:00:13] Finished   devel/py-jsonschema@py311 | py311-jsonschema-4.25.1: Success

Guys, is this acceptable?

Guys, docs updated. Manpages pending.