Skip to content

fix: align setup.py Python version metadata#1

Open
modelsbridgeaicom-ship-it wants to merge 1 commit into
BitgesellOfficial:mainfrom
modelsbridgeaicom-ship-it:codex/nucypher-python-requires
Open

fix: align setup.py Python version metadata#1
modelsbridgeaicom-ship-it wants to merge 1 commit into
BitgesellOfficial:mainfrom
modelsbridgeaicom-ship-it:codex/nucypher-python-requires

Conversation

@modelsbridgeaicom-ship-it

Copy link
Copy Markdown

Summary

  • Align setup.py's supported Python metadata with the rest of the project metadata.
  • pyproject.toml and dependency markers already require Python >=3.9,<4; setup.py still advertised >=3.
  • This prevents pip/build metadata from treating unsupported Python 3.7/3.8 environments as installable targets.

Validation

  • python -m py_compile setup.py
  • git diff --check
  • Confirmed there are no open duplicate PRs in BitgesellOfficial/nucypher for this metadata fix.

Bounty review note: submitting this maintenance fix for consideration under the Bitgesell PR bounty program. Payout details can be provided if the PR is accepted and a maintainer requests them.

@MyTH-zyxeon

Copy link
Copy Markdown

Maintainer-facing review assist for BitgesellOfficial/nucypher#1:

I checked the current PR state and diff. Visible status is OPEN / MERGEABLE / mergeStateStatus=CLEAN at head 33704cbd6964ffcb9b0aec8fb5fcb6bfd62d1330, with no prior comments, reviews, or reported status checks.

The patch is a one-line packaging metadata alignment in setup.py:

  • base setup.py: python_requires='>=3'
  • PR head setup.py: python_requires='>=3.9,<4'
  • existing pyproject.toml: [tool.poetry.dependencies] python = ">=3.9,<4"
  • existing classifiers already list Python 3.9 through 3.12

So the change looks internally consistent and low risk if this fork's setuptools metadata is still maintained. The maintainer decision I would make explicit before merging is whether setup.py remains an authoritative install path for this fork, or whether packaging should be consolidated around pyproject.toml to avoid future drift. If setup.py stays, this PR is the narrow metadata sync; if not, it may be better to close it in favor of removing/deprecating the duplicated setup metadata.

No dependency install, build/test execution, wallet/key action, live-chain action, claim submission, or payment action from me here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants