Skip to content

Validate platforms #12241

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

Closed
wants to merge 20 commits into from
Closed

Conversation

MohsenAAkeel
Copy link

Fixes #6369

This pr adds two bits of functionality:
1. adds validation on user submitted platform tags
Within Issue #6369 was a request to add "error message when the user provides something wrong to any of those (platforms, implementation, python_version, abi) flags. It would be helpful to provide the user’s platform default as an example input." This pr attempts to resolve this for platform tags and set up a simple system to add messages for the remaining flags.

As suggested in issue #6369, the call to validation occurs in the common base class to DownloadCommand and InstallCommand, namely the Command class. The other base classes (RequirementCommand, IndexGroupCommand, and SessionCommandMixin) did not provide appropriate context or opportunity to serve as the place to initiate these checks on the platform tags. The functions that perform the validation are added to cmdoptions.py because this seemed like the most logical place to have them. You'll note that first a function named validate_user_options is called. This is because additional functionality (as discussed in the issue) will be called through this (specifically to check implementation and abi user options). Though the issue calls for an 'error' message, I wasn't sure if this was literal. I decided to make this provide a warning via the logger, especially given that a) it provided for more flexibility for non-standard packages that may exist and b) faulty input for this tag should, as far as I can tell, have no downstream problems since a user will either get exactly what they want or will get the next best package available.

The main functionality is found in validate_platform_options. The main sources of information used to generate the logic here were PEPs 425, 513, 571, 599, and 600. I outline the reasoning for some of the less obvious approaches used.

There is a second pr that will be either already up or up soon that adds validation for --implementation.

Regarding testing. I added a test that should, seemingly work, but could not figure out how to do it!! Beyond running nox, I did local testing with execution of the installed pip to ensure expected behavior.

Final (skippable) note: pip give an ERROR when no matching package is found. The error is vague in that it does not give the exact reason a package could not be found (implementation v platform v abi v etc). However, adding detail here seemed very involved and poor place to add this particular functionality without worrying about all the other potential causes.

2. extends platform help text to include suggestions for valid platform tags
I noticed that some other options (e.g. implementation and python_version) had help text that provided examples, but that the help text for platform did not. I went ahead and added some common examples.

@MohsenAAkeel
Copy link
Author

I'm going to put this back up once I can get testing to work fully!

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Better documentation on using --platform and --python-version
1 participant