Enh: added first language for Python versions#501
Conversation
| (python-version)= | ||
| #### Which Python versions to support? | ||
|
|
||
| But how do I figure out which Python versions I should support? Good question. The Python developer guide provides a [status page](https://devguide.python.org/versions/) (and a handy visualization) that explains the status of each Python release. Python releases go through several different phases that are explained in [PEP 602](https://peps.python.org/pep-0602/). |
There was a problem hiding this comment.
This paragraph feels more like a tip box to me
| @@ -307,6 +307,14 @@ The `requires-python` field helps pip identify which Python versions that your p | |||
| It is set to a single value. | |||
There was a problem hiding this comment.
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.
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 your pyproject.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 definesrequires-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.
There was a problem hiding this comment.
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.
It is set to a single value.
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.
There was a problem hiding this comment.
sorry about the slow reply here friends.
I remember in Slack talking with Pradyun about requires-python being something we want to add to support pip. So that is why the language is there "we recommend" that you add it.
This way, maintainers are intentional about what versions they do and do not support.
IMO it seems like a good practice for people to be intentional about this. Especially in a world where there i think are still a few 2.x users out there 🙃 Are you OK with this @ucodery ? I do trust both or your opinions here I just also remember Pradyun's comments (which I interpreted as - let's use we recommend)
There was a problem hiding this comment.
I opened a new issue for this discussion. I think it would derail this great PR. With your approval already standing, I will merge this.
|
@all-contributors add @mrgah for code, review |
|
I've put up a pull request to add @mrgah! 🎉 |
|
pre-commit.ci autofix |
lwasser
changed the title
3 participants
Added language for Python releases to tutorials/pyproject-toml.md, following consensus on #17 , with MyST reference target and links to Python developer docs and Scientific Python SPEC 0.