From ed510077667cf7e2c3da55bce0d448d118e6df16 Mon Sep 17 00:00:00 2001 From: slow-but-steady Date: Mon, 7 Aug 2023 11:22:33 -0700 Subject: [PATCH] 0.1.1.post1: Fix `python_requires` value for new PyPI upload check MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - this release does not add any new functionality nor modify existing functionality - **SUMMARY** - see commit 21bd027f40137417248430f7b55ccfad5f69f271 for the initial attempt at fixing the upload error - this change fixed the upload error, but changed the functionality of `python_requires` since any `3.0.N` version of python would become incompatible with this change - see commit d3e02a70e3ef6a7c04f0c4531ff4a3324941281e for the proper fix to the original upload error while maintaining compatibility for any `3.0.N` version of python - **EXPLANATION (taken from pull request thread)** After doing some digging, this is the likely culprit for what caused this problem: - https://github.com/pypa/packaging/pull/407 - which was the result of https://github.com/pypa/packaging/issues/566 (related: https://github.com/pypa/packaging/issues/530 and https://github.com/pypa/packaging/issues/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](https://peps.python.org/pep-0440/#inclusive-ordered-comparison): > 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](https://peps.python.org/pep-0440/#version-scheme). Following the link to the [Version scheme](https://peps.python.org/pep-0440/#version-scheme) section and looking at the specification under the [Public version identifiers](https://peps.python.org/pep-0440/#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 ("After doing some digging, this is the likely culprit for what caused this problem"). 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 commit d3e02a70e3ef6a7c04f0c4531ff4a3324941281e 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](https://discuss.python.org/t/how-to-pin-a-package-to-a-specific-major-version-or-lower/17077/8) on the [How to pin a package to a specific major version or lower](https://discuss.python.org/t/how-to-pin-a-package-to-a-specific-major-version-or-lower/17077) 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 --- python/save_thread_result/__init__.py | 2 +- python/setup.py | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/python/save_thread_result/__init__.py b/python/save_thread_result/__init__.py index e733f36..55e7fdb 100644 --- a/python/save_thread_result/__init__.py +++ b/python/save_thread_result/__init__.py @@ -33,7 +33,7 @@ from datetime import datetime -__version__ = '0.1.1.post0' +__version__ = '0.1.1.post1' _general_documentation = ''' diff --git a/python/setup.py b/python/setup.py index 31613e4..b77f891 100644 --- a/python/setup.py +++ b/python/setup.py @@ -31,7 +31,7 @@ # 3. MAINTENANCE version when they make backwards-compatible bug fixes. # Adopting this approach as a project author allows users to make use of “compatible release” specifiers, where name ~= X.Y requires at least release X.Y, but also allows any later release with a matching MAJOR version. # Python projects adopting semantic versioning should abide by clauses 1-8 of the Semantic Versioning 2.0.0 specification: https://semver.org/. - version = '0.1.1.post0', + version = '0.1.1.post1', name = 'save-thread-result', description = 'Simple subclass wrapper around `threading.Thread` to get the return value from a thread in python. Exact same interface as `threading.Thread`! 🌟 Star this repo if you found it useful! 🌟', long_description = long_description,