Ned Deily added the comment: 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 python.org, 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! ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27593> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
