It took me countless hours, but these do build:

archivers/py-cramjam chinese/py-rjieba databases/py-datafusion databases/py-sqlglotrs databases/py-sqloxide devel/py-tox-toml-fmt devel/py-deptry devel/py-qcs-sdk-python devel/py-regress devel/py-rpds-py devel/py-ruff devel/py-pyperscan devel/py-pyproject-fmt-rust devel/py-jellyfish devel/py-orjson devel/py-pendulum devel/py-pydantic-core devel/py-pyproject-fmt devel/py-ty devel/py-watchfiles devel/py-pycrdt devel/py-dbt-extractor devel/py-ormsgpack devel/py-fastuuid devel/py-uv-build08 lang/py-dhall math/py-clarabel math/py-pcodec misc/py-lazrs misc/py-hf-xet misc/py-polars misc/py-pyqir misc/py-safetensors www/py-adblock www/py-jh2 www/py-nh3 www/py-qh3 www/py-granian www/py-pywry www/py-primp security/py-cryptography textproc/py-pycddl textproc/py-jiter textproc/py-tokenizers textproc/py-textual-speedups x11-fonts/py-shaperglot

In D53687#1226367, @kai wrote:

Please check beforehand whether devel/py-maturin builds on all Tier1 FreeBSD releases (maybe CURRENT as well, if possible) and that the consumers (retrievable e.g. with portgrep -o -s -d py-maturin) also builds fine.
Otherwise, LGTM and thank you very much!

Now use "make cargo-crates"

Recreate crates list

In D53686#1226200, @tagattie wrote:

Hi @michaelo, thanks for an update to the port.

It appears some updates to CARGO_CRATES and distinfo are missing.

Can you update Makefile.crates using make cargo-crates and resubmit the patch?

Thanks!

truss output:

root@135-release-amd64-default-head:/usr/ports/devel/uv # grep /usr/local/etc --color out
read(3,"includedir /usr/local/etc/libmap"...,35) = 35 (0x23)
open("/usr/local/etc/libmap.d",O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,0165) ERR#2 'No such file or directory'
fstatat(AT_FDCWD,"/usr/local/etc/xdg/uv/uv.toml",0x348e6c167210,0x0) ERR#2 'No such file or directory'
fstatat(AT_FDCWD,"/usr/local/etc/uv/uv.toml",0x348e6c167210,0x0) ERR#2 'No such file or directory'
root@135-release-amd64-default-head:/usr/ports/devel/uv #

Creates file produced by:

awk '/name = / { gsub(/"/, "", $3); name=$3 } /version = / { gsub(/"/, "", $3); print "\t\t" name "-" $3 " \\" }' Cargo.lock | sort -u > ../../Makefile.crates

Manually applied by maintainer.

Updating the patch making bdist_wheel opt-in.

In D53489#1225670, @mikael wrote:

It's not possible to mfh it, rust is at 1.89.0 in Q4.
It's probably possible to do a direct commit in Q4 but I've never done that. Feel free to do it if you think Q4 needs this patch.

Reivew has been ignored by maintainer.

Reivew has been ignored by maintainer.

In D53489#1224813, @mikael wrote:

I'll commit your patch prior to landing rust 1.91.0 (to not bump rust too frequently, people will get mad at me otherwise)
I'll drop the version in the file name (it's a pain to maintain in the long run) -> files/patch-vendor_openssl-probe_src_lib.rs

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?