Upper limits are incorrect in requires-python

[henryiii]

Describe the Bug

On adding Python 3.13 to my testing matrix (coverage.py supports Python 3.13a6+), I was quite confused to see "CoverageWarning: Unrecognized option '[tool.coverage.report]" warnings. Checking the package resolution, I was getting strangely old versions:

Run uv pip install --system pip install coveralls pytest-github-actions-annotate-failures
Resolved 15 packages in 777ms
Downloaded 14 packages in 942ms
Installed 14 packages in 4ms
 + certifi==2024.2.2
 + charset-normalizer==3.3.2
 + coverage==6.5.0
 + coveralls==3.3.1
 + docopt==0.6.2
 + idna==3.7
 + iniconfig==2.0.0
 + install==1.3.5
 + packaging==24.0
 + pluggy==1.5.0
 + pytest==8.2.1
 + pytest-github-actions-annotate-failures==0.2.0
 + requests==2.31.0
 + urllib3==2.2.1

That usually means one thing: someone didn't understand that capping the python version doesn't work. I tracked it down to this package. I have more detail here, but in short, python-requires is used for two things:

• Solvers like pip and uv use it to back solve. If it doesn't match, they look for older packages until it does match. So instead of proceeding a nice error message (which I assume was the intention), coveralls==3.3.1 is installed instead. Even if every older version of the package was removed, the error message is still terrible, by the way, with "no package found" instead of stating something about the limit. Package solvers don't have any understanding of why something fails, so lower an upper bounds are treated the same.
• Locking systems like Poetry and PDM use this to come up with a lock file that works across a range of Python versions. That means a package can't lock on this package without also putting the package limit to 3.13 (which is wrong), or limiting this package to only <3.13, which is also wrong.

You should either let the use see the actual problem, or if you absolutely sure it will break, you can add dynamic SDist code (like in a setup.py for setuptools) to check the Python version there. This is what Numba does, after reverting the upper limit, since there is a zero percent chance it will work on a new version of Python. Other packages that added then reverted an upper limit include NumPy.

I'd expect this package actually depends on coverage.py working, which will start working (Ned makes sure of this well before the beta's even) without a code change here.

To Reproduce
Steps to reproduce the behavior:

Try to install on Python 3.13:

- uses: actions/setup-python@v5
  with:
    python-version: "3.13"
    allow-prereleases: true
- run: pip install coveralls

Expected Behavior

I expect to see the actual problem with 3.13 (if there is one) so I can report it and fix it.

FYI, I worked around this by using:

- run: pipx run coveralls

Which grabs the older version of coveralls, but coveralls even back then was not actually incompatible with Python 3.13, so it works fine.