Since we are going to be switching over to Git, sys._mercurial is going to be made to return a dummy value of `('CPython', '', '')` once we switch to Git. But my question is do we bother to replace it with sys._git? I wanted to make sure that the effort is worth it to keep changing these VCS-specific attributes every time we change our VCS (and no, we are not going to adopt a generic one; already had that debate). So do please speak up if you actually have found value from sys._mercurial.
On 23 January 2016 at 09:44, Brett Cannon <brett@python.org> wrote:
Since we are going to be switching over to Git, sys._mercurial is going to be made to return a dummy value of `('CPython', '', '')` once we switch to Git. But my question is do we bother to replace it with sys._git? I wanted to make sure that the effort is worth it to keep changing these VCS-specific attributes every time we change our VCS (and no, we are not going to adopt a generic one; already had that debate). So do please speak up if you actually have found value from sys._mercurial.
It's incorporated into the output of "platform.python_(branch|revision|build)()", so I assume most people would use those if they needed to report exact build information, rather than accessing the attribute directly. We also use it ourselves in printing the appropriate banner when running an interactive prompt (note the first line of the banner): Python 3.6.0a0 (default:32a4e7b337c9, Jan 23 2016, 12:30:00) [GCC 5.3.1 20151207 (Red Hat 5.3.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information.
import sys sys._mercurial ('CPython', 'default', '32a4e7b337c9')
And the regression test suite: $ ./python -m test == CPython 3.6.0a0 (default:32a4e7b337c9, Jan 23 2016, 12:30:00) [GCC 5.3.1 20151207 (Red Hat 5.3.1-2)] == Linux-4.3.3-301.fc23.x86_64-x86_64-with-fedora-23-Twenty_Three little-endian == hash algorithm: siphash24 64bit == /home/ncoghlan/devel/cpython/build/test_python_13167 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [ 1/401] test_grammar ... I guess that means "Update platform.py, and test the interactive prompt and regression test banners still work as expected when built from git" needs to be added to the CPython migration part of the PEP. (In looking into this, I found several of the docstrings in platform.py still referred to Subversion, even though the platform._sys_version() helping had been updated to handle Mercurial) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Jan 22, 2016, at 18:44, Brett Cannon <brett@python.org> wrote:
Since we are going to be switching over to Git, sys._mercurial is going to be made to return a dummy value of `('CPython', '', '')` once we switch to Git. But my question is do we bother to replace it with sys._git? I wanted to make sure that the effort is worth it to keep changing these VCS-specific attributes every time we change our VCS (and no, we are not going to adopt a generic one; already had that debate). So do please speak up if you actually have found value from sys._mercurial.
As long as the git revision tag (if any) and hash show up in sys.version and the interpreter interactive (REPL) mode header as they do today with hg and previously with svn (that is, when the interpreter is built from a vcs checkout), I'm happy: $ python3 Python 3.5.1 (v3.5.1:37a07cee5969, Dec 5 2015, 21:12:44) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information.
-- Ned Deily nad@python.org -- []
It seems that people do use the values so there will be a sys._git attribute. On Fri, 22 Jan 2016 at 19:57 Ned Deily <nad@python.org> wrote:
On Jan 22, 2016, at 18:44, Brett Cannon <brett@python.org> wrote:
Since we are going to be switching over to Git, sys._mercurial is going to be made to return a dummy value of `('CPython', '', '')` once we switch to Git. But my question is do we bother to replace it with sys._git? I wanted to make sure that the effort is worth it to keep changing these VCS-specific attributes every time we change our VCS (and no, we are not going to adopt a generic one; already had that debate). So do please speak up if you actually have found value from sys._mercurial.
As long as the git revision tag (if any) and hash show up in sys.version and the interpreter interactive (REPL) mode header as they do today with hg and previously with svn (that is, when the interpreter is built from a vcs checkout), I'm happy:
$ python3 Python 3.5.1 (v3.5.1:37a07cee5969, Dec 5 2015, 21:12:44) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information.
-- Ned Deily nad@python.org -- []
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org
Hi, On 01/23/2016 12:44 AM, Brett Cannon wrote:
Since we are going to be switching over to Git, sys._mercurial is going to be made to return a dummy value of `('CPython', '', '')` once we switch to Git.
for me sys._mercurial it's already returning that (?) : what should return now? (it's a bug?) $ ipython Python 2.7.11 (default, Dec 9 2015, 00:29:25) Type "copyright", "credits" or "license" for more information. IPython 2.4.1 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object', use 'object??' for extra details. In [1]: import sys In [2]: sys._mercurial Out[2]: ('CPython', '', '') In [3]: Regards, francis
On Sat, 23 Jan 2016 at 11:45 francismb <francismb@email.de> wrote:
Hi,
On 01/23/2016 12:44 AM, Brett Cannon wrote:
Since we are going to be switching over to Git, sys._mercurial is going to be made to return a dummy value of `('CPython', '', '')` once we switch to Git.
for me sys._mercurial it's already returning that (?) : what should return now? (it's a bug?)
Depends on your OS and how CPython was built whether it returns that value or something more useful. IOW it's not a bug.
On 24 January 2016 at 05:48, Brett Cannon <brett@python.org> wrote:
On Sat, 23 Jan 2016 at 11:45 francismb <francismb@email.de> wrote:
for me sys._mercurial it's already returning that (?) : what should return now? (it's a bug?)
Depends on your OS and how CPython was built whether it returns that value or something more useful. IOW it's not a bug.
Linux distros tend to build Python from a tarball rather than a source checkout, for example, which means the build directory doesn't include any VCS details: $ python3 Python 3.4.3 (default, Jun 29 2015, 12:16:01) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux Type "help", "copyright", "credits" or "license" for more information.
import sys sys._mercurial ('CPython', '', '')
While my local checkout does have those details: $ ./python Python 3.6.0a0 (default:32a4e7b337c9, Jan 23 2016, 12:30:00) [GCC 5.3.1 20151207 (Red Hat 5.3.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information.
import sys sys._mercurial ('CPython', 'default', '32a4e7b337c9')
Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Hi, On 01/24/2016 01:17 PM, Nick Coghlan wrote:
Linux distros tend to build Python from a tarball rather than a source checkout, for example, which means the build directory doesn't include any VCS details:
Does that helps traceability (reproducibility)? If distros use (?) the tarball from the release why it doesn't have, at least, the information from where that tarball was generated from (the check out point) ? Regards, francis
francismb writes:
Does that helps traceability (reproducibility)? If distros use (?) the tarball from the release why it doesn't have, at least, the information from where that tarball was generated from (the check out point) ?
The pointer goes in the other direction: there will be a tag in the repo named to indicate the version.
On 25 January 2016 at 03:40, francismb <francismb@email.de> wrote:
On 01/24/2016 01:17 PM, Nick Coghlan wrote:
Linux distros tend to build Python from a tarball rather than a source checkout, for example, which means the build directory doesn't include any VCS details: Does that helps traceability (reproducibility)? If distros use (?) the tarball from the release why it doesn't have, at least, the information from where that tarball was generated from (the check out point) ?
The main reason is that distro packaging processes long predate Subversion's popularisation of atomic commits in open source version control tools, and are designed to cope with release processes that involve uploading a source tarball to a web server, so they don't assume VCS tags or revision IDs will be available. However, distro processes also capture the source code itself, and often apply additional distro-specific patches, at which point claiming to correspond directly to any given upstream commit would be inaccurate. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Some discussion happened on core-workflow@, otherwise you can look through the python-dev archives for when we added sys._mercurial. On Sat, 23 Jan 2016, 16:25 Random832 <random832@fastmail.com> wrote:
Brett Cannon <brett@python.org> writes:
(and no, we are not going to adopt a generic one; already had that debate).
Do you have a link to the relevant discussions?
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org
On 24 January 2016 at 10:29, Brett Cannon <brett@python.org> wrote:
Some discussion happened on core-workflow@, otherwise you can look through the python-dev archives for when we added sys._mercurial.
We actually forgot one relevant point in those discussions: there's already a generic API for accessing this information in the platform module. At the sys module level, though, the key point is that the precise semantic interpretation is VCS dependent, so changing the variable name conveys immediately to users both that the semantics have changed, and which VCS is now being used to define them. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (6)
-
Brett Cannon -
francismb -
Ned Deily -
Nick Coghlan -
Random832 -
Stephen J. Turnbull