fix: bound the generated Python range so poetry can resolve dependencies - #181
Open
AdamerGitHub wants to merge 1 commit into
Open
fix: bound the generated Python range so poetry can resolve dependencies#181AdamerGitHub wants to merge 1 commit into
AdamerGitHub wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #180
poetry lockandpoetry installfail on a clean checkout of master. This makes the declared Python range match what the dependencies actually allow, without changing which Python versions are supported.What is wrong
scripts/poetry_fix.pygenerates thepythonconstraint inpyproject.toml, and its "all versions" value has no upper bound:With no upper bound, Poetry has to find a solution that also holds for Python 3.14, 3.15 and beyond, up to and including 4.x. Nothing satisfies that. The solver reports
hypexfirst (no release goes above<3.14), and once that is excluded it fails onfeaturetools, which requires<4— as do most packages on PyPI.Because the constraint is generated, editing line 34 by hand does not help: the
set-py-versionspre-commit hook rewrites it back on the next run. The fix has to go into the constant.What this changes
ALL_PYTHON_DEPSbecomes">=3.8,<4.0", andpyproject.tomlpicks that up through the hook.hypexgetspython = "<3.14", since no published release supports 3.14.No supported Python version is dropped.
<4.0only excludes Python 4, which does not exist — and which the package could not have been installed on anyway, since the requiredfeaturetoolsalready caps at<4. The marker onhypexdoes not restrict anything new either: there is nohypexrelease that works on 3.14, so on that version pip now skips the extra cleanly instead of failing to install it.Verification
Fails on master; resolves in ~2 minutes with this change.
pre-commit run --all-filespasses, includingset-py-versions, which no longer rewritespyproject.toml— the constant and the generated line now agree.Why CI did not catch it
tox.iniinstalls withpip install -e .[all], and pip only checksrequires-pythonagainst the running interpreter instead of solving across a range. The docs workflows call the script with-c, which pins a single version (~3.11.0) and resolves trivially. The one line intox.inithat would have exercised-fis commented out, so the "all versions" path is never run in CI.Note
poetry checkreports separate, pre-existing errors on master aboutscikit-imageandefficientnet-pytorchbeing listed in[tool.poetry.extras]without being declared as optional dependencies. Unrelated to this change; I will open a separate issue.