Version 2.7.0 Released in January 2023 was updated recently to remove support for Python 3.7 about portalocker

[wolph]

It seems that during the testing of the new build system a new python 3 only wheel was created as opposed to the universal wheel that already existed. During the upload of the 2.8.x release that file was uploaded by twine as well.

I've removed the file and it should not happen in the future but I'll check more thoroughly later today.

[martin-pil]

The newest whl release for 2.7.0 has different python requirements then the older releases

pip install "portalocker==2.7.0"
Collecting portalocker==2.7.0
Downloading portalocker-2.7.0-py3-none-any.whl (22 kB)
ERROR: Package 'portalocker' requires a different Python: 3.7.3 not in '>=3.8'

[hugovk]

Ah right, now I see: https://pypi.org/project/portalocker/2.7.0/#files

It looks like portalocker-2.7.0-py3-none-any.whl was uploaded by mistake. I recommend that file is deleted from PyPI.

[hugovk]

I believe version 2.7.0 remains unchanged.

Support for Python 3.7 was removed in 2.8.0.

If you're using Python 3.7, the metadata changed in #85 to python_requires='>=3.8' means pip will still install the last version supporting your Python: 2.7.0.

[notshof]

I believe version 2.7.0 remains unchanged.

Support for Python 3.7 was removed in 2.8.0.

If you're using Python 3.7, the metadata changed in #85 to python_requires='>=3.8 means pip will still install the last version supporting your Python: 2.7.0.

Hello, it changed, I am trying to use it, it only accepts >=3.8. Check on Pypi it says updated September 16.

Thanks for the prompt reply.

[hugovk]

https://pypi.org/project/portalocker/ says "Released: Sep 16, 2023" and "Requires: Python >=3.8", referring to 2.8.2.

https://pypi.org/project/portalocker/2.7.0/ says "Released: Jan 19, 2023" and "Requires: Python >=3.5".

Perhaps you could tell us what you're trying to do exactly, and what errors you're seeing? Please copy and paste the output.

[notshof]

Hey, 2.7.0 says released Jan 19 2023, but uploaded Sep 16 2023 for
portalocker-2.7.0-py3-none-any.whl, which I believe only supports >=3.8 which is causing issues.

[notshof]

Thanks for the fast resolution.

[wolph]

I've modified my build and upload script to only upload files from the specific current version. So if the naming of wheel files ever changes in the future, we shouldn't be able to get this anymore

[hugovk]

Sounds good, thanks!

By the way, for comparison, I usually create a RELEASING.md checklist in the repo to follow. For example, I do the build and upload from a clean directory:

• https://github.com/python-humanize/humanize/blob/06da03257f303dfa1d924866426949bab11b0243/RELEASING.md

Better yet, use PyPI's "Trusted Publishers" and automate deploy via GitHub Actions:

• https://github.com/termcolor/termcolor/blob/609f40477e602b93ec3ebef511578041752601b0/RELEASING.md
• https://blog.pypi.org/posts/2023-04-20-introducing-trusted-publishers/

[wolph]

To avoid many of those issues I have a single build and deploy script that I use for all of the packages I maintain. It automatically cleans all build files, runs tests, builds the packages, signs all the files, creates a github release and uploads to pypi. The one directory that I don't clear however (also because it's an archive to check for issues later) is the dist directory which was the culprit here.

And while I do like the trusted publishers system for deploying through Github actions (I actually use it for my speedups library), I want to sign all files with my personal GPG key and uploading my private GPG key to GitHub makes it all but futile to even use it ;)

[hugovk]

PyPI have removed support for GPG: https://blog.pypi.org/posts/2023-05-23-removing-pgp/

If you are someone who is currently uploading signatures, your package uploads will continue to succeed, but any PGP signatures will be silently ignored.

[wolph]

Yes, I'm aware and it's a decision I strongly disagree with.
They are currently still part of the upload process but I'm not sure if they can still be downloaded.

I'm currently in the process of adding my signature files to the GitHub releases so package maintainers can still verify them if they want because some of my code is used by many other packages/people/business.