Add `devel` field to `sys.version_info`

[FFY00]

Feature or enhancement

Proposal:

The idea is to add a new field to sys.version_info to specify if we are on a development build (non-tagged commit). For backwards compatibility, sys.version_info should still only produce a 5-field sequence when unpacking.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

Discussed in https://discuss.python.org/t/pep-739-static-description-file-for-build-details-of-python-installations/44572/67

Linked PRs

• GH-122123: show all named fields in the PyStructSequence repr #122124
• GH-122123: add devel field to sys.version_info #122125

[vstinner]

I dislike "devel" term, it's vague.

• What if you apply a local patch on a tag? Is it a "devel" version?
• What if you are on the main branch? Is it a "devel" version?
• What if you downloaded an archive (tar, zip, whatever) of Python source code? It doesn't have the .git/ directory. Is it a "devel" version? What if the code is modified?
• Linux distributions usually have downstream patches. Does it tag a version as "devel"?

I would prefer a different term for that. Also, you didn't provide the rationale for adding a new member for sys.version_info. What's the intended use case? PEP 739 doesn't mention "devel".

I would prefer a new sys or sysconfig attribute with more details information:

• Is it a git checkout?
• What is the git branch name?
• Is the git checkout dirty?

sys.version already contains some of these information, but as a string, it's less pratical to use.

[vstinner]

Maybe sys._git should become a namedtuple and it should be completed?

[zooba]

The comment from the linked thread is:

implementation.version.releaselevel: it doesn’t include a dev/devel option, please consider adding that.

I disagree with the suggestion entirely. I certainly don't want my patched builds to be visibly marked as "dirty" - that's putting way too much of an "official" tag on the python.org releases, which is not CPython's culture at all (though many people seem to think it is, and I really want to disabuse them of that misconception).

A separate field in the static description file capturing the source repository and commit/tag ought to be sufficient. Basically sys._git.

[rgommers]

I think my Discourse comment was misinterpreted. My point was that Python packages (and lots of other software) normally have a way to indicate that something is a development version, in addition to pre-release suffixes. PEP 440 has content to formalize this for Python packages, they should use .devN. For a Python build, there is no such standard. My suggestion was to clarify that. @FFY00 commented afterwards that CPython uses .a0 for this. If that is the case also for all other Python interpreters, then a comment stating that .a0 means dev version will suffice. If not and say PyPy or GraalPy prefer .dev, then it seems like it needs adding to PEP 739. Either way, nothing needs changing in CPython itself.