Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle unsupported python versioning on Pipfile #6164

Merged

Conversation

sanspareilsmyn
Copy link
Contributor

@sanspareilsmyn sanspareilsmyn commented May 24, 2024

The issue

This is a bug fix of Pipfile [requires] regards to #6144
Pipenv only supports absolute python version. If the user specifies a Python version with inequality signs like >=3.12, <3.12 in the [requires] field, the code has been modified to explicitly express in an error log that absolute versioning must be used.

The fix

  • Add protection logic to parse python verison on Pipfile.
  • Enhance error log that absolute versioning must be used.
  • Add test codes.

The checklist

  • Associated issue
  • A news fragment in the news/ directory to describe this fix with the extension .bugfix.rst, .feature.rst, .behavior.rst, .doc.rst. .vendor.rst. or .trivial.rst (this will appear in the release changelog). Use semantic line breaks and name the file after the issue number or the PR #.

@sanspareilsmyn sanspareilsmyn force-pushed the handle-unspecified-python-version branch from 7daf34d to b2dafaa Compare May 24, 2024 12:35
@sanspareilsmyn sanspareilsmyn force-pushed the handle-unspecified-python-version branch from e6fbda8 to ad77f63 Compare May 24, 2024 12:37
if python:
range_pattern = r"^[<>]=?|!="
if re.search(range_pattern, python):
click.echo(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have been migrating away from click.echo to use the rich console -- you can find other examples in the code of how to print the equivalent thing using that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@matteius Thanks for guidance. I'll check and modify it to the convention.

),
err=True,
)
abort()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe abort is fine, not sure how it behaves different then the other runtime errors we raise--just calling out this is an uncommon pattern in the project so deserves additional thought to standardize on a best approach.

Copy link
Contributor Author

@sanspareilsmyn sanspareilsmyn May 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@matteius I'll think about it more about how to handle the runtime errors in another ways. It would be glad for me for you to recommend some references if it's available!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about sys.exit(1)? That is what I am using in my PR to clean up and not render a stack error trace when resolver fails.

@sanspareilsmyn sanspareilsmyn requested a review from matteius May 27, 2024 07:31
@matteius matteius merged commit 6abb08c into pypa:main Jun 3, 2024
18 of 19 checks passed
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