Fix parsing error on python_requires >=3.0.* by simplifying to >=3

[YSaxon]

Under certain circumstances the existing python_requires string fails out the parser and causes the pip install to fail. Simplifying it should fix that.

[shailshouryya]

Hi YSaxon, thanks so much for making this fix! I just ran into something similar when I tried uploading this package to PyPI just now, which I worked around with commit 21bd027 - however, I think your approach is better since it maintains the >= (my update changes the comparison to >), and I also didn't quite understand what caused the python_requires check to start failing.

Can you give a quick explanation of what the reason for this failure is/why this change fixes it?

Also, thank you for following the same style I've been using for the git commit messages - I've been meaning to add a CONTRIBUTING.md for this, but you were very consistent even without it!

[shailshouryya]

Also, looks like I rebased my commits and created conflicts with your original fix 😅 - would you prefer to rebase your change on top of my rebase (probably something like git pull origin upstream --rebase) or would you prefer me to fix the conflicts up here and merge in your change?

[shailshouryya]

I didn't close this pull request, but I was playing around with the branches earlier and it looks like GitHub automatically closes any pull requests that are associated with a particular branch that gets modified, which is interesting - but not ideal here 😂

Your changes look good to me though!

[shailshouryya]

Did some digging and found the likely culprit for what caused this problem:

• Drop LegacySpecifier and LegacyVersion pypa/packaging#407
  • which was the result of Disallow * version modifier for anything but == and != pypa/packaging#566 (related: Removal of LegacyVersion and LegacySpecifier pypa/packaging#530 and Deprecate LegacyVersion/LegacySpecifier pypa/packaging#321)
    • which in turn looks like the result of the discussion at https://discuss.python.org/t/how-to-pin-a-package-to-a-specific-major-version-or-lower/17077/8

It looks like this is the expected behavior as defined in PEP 440 under the Inclusive ordered comparison section:

An inclusive ordered comparison clause includes a comparison operator and a version identifier, and will match any version where the comparison is correct based on the relative position of the candidate version and the specified version given the consistent ordering defined by the standard Version scheme.

Following the link to the Version scheme section and looking at the specification under the Public version identifiers section:

The canonical public version identifiers MUST comply with the following scheme:
[N!]N(.N)*[{a|b|rc}N][.postN][.devN]
Public version identifiers MUST NOT include leading or trailing whitespace.

Public version identifiers MUST be unique within a given distribution.
...

The last line included above seems to be the "loose implementation" of the version modifier that the issues and pull requests I linked to at the very top were discussing ("Did some digging and found the likely culprit").

Once that "loose implementation" was fixed, any package that didn't follow the PEP 440 specification for version identifiers broke. In this package, the break occurred because of the >=3.0.* comparison, which IS NOT unique within a given distribution, as opposed to >=3 (what your fix here does), which IS unique within a given distribution.

To clarify: it looks like the problem we see in this issue is because of implementation fixes in the packaging tools to more closely follow PEP 440, specifically "Public version identifiers MUST be unique within a given distribution." Any package that relied on the previous implementation that loosely verified the PEP 440 specification but did not strictly follow PEP 440 broke after the implementation of the packaging tool(s) were fixed to more closely follow PEP 440. More explicitly (from this comment on the How to pin a package to a specific major version or lower discussion):

Christopher already made the response I was going to make: for PEP 440 as written, using wildcards outside of “==” and “!=” comparisons isn’t valid.

Allowing them for “>=” and “<=” would be reasonable, but it would involve a PEP to fix the spec. (It wasn’t a conscious choice to exclude them, we just didn’t notice at the time that the inclusive ordered comparison operators weren’t formally defined as combining an exclusive ordered comparison with a version match, so the tools have been written to ignore the wildcard instead of paying attention to it)

Making a coherent definition wouldn’t be too hard: just ignore the wildcard for the exclusive ordered comparison part and keep it for the version matching part.

Here are some other posts that aren't directly relevant, but might be interesting tangents for anyone interested in packaging problems:

• https://stackoverflow.com/questions/19534896/enforcing-python-version-in-setup-py
  • https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/#python-requires
  • https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/#package-data
    • https://setuptools.pypa.io/en/latest/userguide/datafiles.html
      • https://peps.python.org/pep-0345/#requires-python
• https://stackoverflow.com/questions/8795617/how-to-pip-install-a-package-with-min-and-max-version-range
• https://python3statement.org/practicalities/
• https://discuss.python.org/t/requires-python-upper-limits/12663/20
• https://stackoverflow.com/questions/13924931/setup-py-restrict-the-allowable-version-of-the-python-interpreter/13925176#13925176

[shailshouryya]

Oof, the merge/rebase diff is a bit ugly here 😅 - here might be a simpler way to resolve the conflicts:

1. Go to your fork of the repo on your terminal/command prompt: cd /path/to/save-thread-result
2. Switch to the main branch of the fork: git checkout main
3. Remove the conflicting commit because of my rebase: git reset --hard HEAD~1
4. Sync this removed commit to your remote repository: git push --force origin main (you need the --force option since this is removing a commit)
5. Go to your fork on the GitHub UI and click the Sync fork button under the |Go to file| |Add file| |<> Code| buttons. You should get a dropdown that says something like the following with a green Update branch button at the bottom:

This branch is out-of-date
Update branch to keep this branch up-to-date by syncing N commits from the upstream repository.
Learn more

7. Click the Update branch button.
8. Pull the updated, synchronized git commits to your local repository: git pull origin main
9. Apply your fix here: git cherry-pick 41ebc90af1b56c4c5257cfd071b926900e3b5ec5
   a. This is probably where you'll get the merge conflict - this one should be much simpler though, and only have a conflict in the setup.py file - resolve the conflict here
   b. Commit the resolved conflicts: git add python/setup.py && git commit
   c. Update your patch-1 branch: git branch -D patch-1 && git checkout -b patch-1
10. Push the resolved fixes to the branch: git push --force origin patch-1 (you'll probably need the --force flag again because the git history has diverged)

I think this should be enough to resolve the conflicting files issue - let me know if you run into any problems though!

[YSaxon]

Thanks for the detailed steps, and the followup. Let me know if this works

[shailshouryya]

This, works, thank you! 🎉