This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ned.deily
Recipients benjamin.peterson, brett.cannon, larry, matrixise, ned.deily, steve.dower
Date 2017-03-04.04:12:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I finally took a close look at this and I think the approach Brett advocated here is a bit too simple and does not cover the use case I had in mind when I suggested we needed to have a replacement for sys._mercurial.  Previously when building from a source repo, if the repo was checked out to a tag (like a release tag, say, "v3.6.0"), that tag showed up in sys._mercurial and sys.version making it very easy to identify release builds.  For example, with the macOS pythons we provide on, you see versions like this:

$ /usr/local/bin/python3.5 -c 'import sys;print(sys.version)'
3.5.2 (v3.5.2:4def2a2901a5, Jun 26 2016, 10:
$ /usr/local/bin/python3.5
Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 26 2016, 10:47:25)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D

Having the tag, if available, is very important, IMO.  Also, the original patch didn't deal with the platform module which also uses the SCM info.

Since we've now made the transition to git, it seems to me there's no reason to complicate the code by trying to support either hg or git; we don't support svn anymore.  So the PR is simpler and follows very much the hg support.  I think this also means that Steve's PR for the Windows installer should be changed back to use tags again.  I'd like to get this into 3.6.1 if possible.   Better late than never!
Date User Action Args
2017-03-04 04:12:15ned.deilysetrecipients: + ned.deily, brett.cannon, larry, benjamin.peterson, steve.dower, matrixise
2017-03-04 04:12:15ned.deilysetmessageid: <>
2017-03-04 04:12:14ned.deilylinkissue27593 messages
2017-03-04 04:12:14ned.deilycreate