requirements: bump twine to ~= 6.0

[woodruffw]

The locked requirements now resolve 6.0.1.

Closes #308.

[woodruffw]

@webknjaz Could you give this a peek when you get a chance? I suspect a lot of Maturin-based builds are going to begin to run into issues here, like we're seeing here: https://github.com/trailofbits/rfc3161-client/actions/runs/12122650623/job/33796528057

[davidhewitt]

If I can also please add my request for this to be reviewed: due to an unfortunate bug in PyO3 0.23 there will probably be a lot of builds in the coming days to release new versions of Rust / maturin based projects without corrupted wheels.

It would be helpful if this could be merged so all those projects don't have to go through a dance pinning back maturin / twine / this action. Thanks in advance 🙏

[webknjaz]

@woodruffw thanks! I hope I'll get to releasing this today.

[samuelcolvin]

Thanks so much @webknjaz.

[davidhewitt]

Thanks! 🎉

[cdump]

Hi. Looks like twine upgrade is not enough, tested on whl build with pyo3/maturin 0.23.3
unstable-v1 image hash = 83623c34c365

$ podman run -v `pwd`:/mnt --entrypoint /bin/bash --rm -it ghcr.io/pypa/gh-action-pypi-publish:unstable-v1

root@910b2e56a188:/app# twine --version
twine version 6.0.1 (keyring: 25.2.1, pkginfo: 1.10.0, requests: 2.32.3, requests-toolbelt: 1.0.0,
urllib3: 2.2.1)

root@910b2e56a188:/app# twine check /mnt/*.whl
Checking /mnt/evmole-0.6.1-cp310-cp310-macosx_10_12_x86_64.macosx_11_0_arm64.macosx_10_12_universal2.whl: ERROR    InvalidDistribution: Metadata is missing required fields: Name, Version.
         Make sure the distribution includes the files where those fields are specified, and is using a
         supported Metadata-Version: 1.0, 1.1, 1.2, 2.0, 2.1, 2.2, 2.3.


root@910b2e56a188:/app# pip3 install pkginfo --upgrade
..
Successfully installed pkginfo-1.12.0

root@910b2e56a188:/app# twine check /mnt/*.whl
Checking /mnt/evmole-0.6.1-cp310-cp310-macosx_10_12_x86_64.macosx_11_0_arm64.macosx_10_12_universal2.whl: PASSED

#310

[webknjaz]

I just realized that we didn't really need to cap this below v7 since this input file is not used w/o the constraints anyway: 67339c7