-
Notifications
You must be signed in to change notification settings - Fork 62
added first language for Python versions #501
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
Open
mrgah
wants to merge
4
commits into
pyOpenSci:main
Choose a base branch
from
mrgah:add-py-versions
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realize this PR was opened just to add new guidance, but we should really update this paragraph to specify that, even with lower bounds,
requires-python
is not necessary for every package and is only something to be used when the author has confidence there are versions of Python the package versions Must Not be installed for.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it seems like there's a bit of an open question about how to frame this. what about something like the following?
We recommend adding the
requires-python
field to yourpyproject.toml
[project]
table.This is not mandatory, but the
requires-python
field helps pip identify which Python versions that your package supports, and is only required when there are versions of Python the package will not work with.It is set to a single value.
The packaging specification defines
requires-python
as a string that uses version specifiers. Most projects will specify the oldest Python version supported by the package. In some advanced cases, an upper bound is set to indicate which future Python versions, if any, will be supported.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO "We recommend" is still too strong. @lwasser I might have missed some conversation this week, but I believe we recommend leaving it out, until a version of Python is known to break the package.
This might just be my reading of the guide, but this sounds like the field takes a single version string. It takes a single version specifier which is a version operator plus version string, maybe multiple. But we should specify that the only versions specifier we recommend is
> 3.X.Y
or>= 3.X.Y
. I am against even mentioning an upper bound, and would probably be okay saying to not do that, although that can just add confusion. Not sure Leah's thought on the upper.