Skip to content

Add test.pythoninfo #75054

Closed
Closed

Description

@vstinner
BPO 30871
Nosy @terryjreedy, @ncoghlan, @vstinner, @berkerpeksag, @serhiy-storchaka, @pablogsal
PRs
  • bpo-30871: Add test.pythoninfo #3075
  • bpo-29854: Print readline version information when running test suite #2618
  • bpo-30871: Add "make pythoninfo" #3120
  • bpo-30871: pythoninfo: add expat and _decimal #3121
  • bpo-30871: pythoninfo: more sys, os, time data #3130
  • bpo-31231: Fix pythoninfo in Travis config #3134
  • [3.6] bpo-30871: Add test.pythoninfo #3174
  • [2.7] bpo-30871: Add test.pythoninfo (#3174) #3175
  • Files
  • pythoninfo.py
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = <Date 2018-08-12.15:59:59.056>
    created_at = <Date 2017-07-07.14:48:35.518>
    labels = ['3.7', 'type-feature', 'tests']
    title = 'Add test.pythoninfo'
    updated_at = <Date 2018-08-12.15:59:59.054>
    user = 'https://github.com/vstinner'

    bugs.python.org fields:

    activity = <Date 2018-08-12.15:59:59.054>
    actor = 'pablogsal'
    assignee = 'none'
    closed = True
    closed_date = <Date 2018-08-12.15:59:59.056>
    closer = 'pablogsal'
    components = ['Tests']
    creation = <Date 2017-07-07.14:48:35.518>
    creator = 'vstinner'
    dependencies = []
    files = ['46994']
    hgrepos = []
    issue_num = 30871
    keywords = []
    message_count = 30.0
    messages = ['297885', '297888', '297891', '300168', '300169', '300183', '300215', '300347', '300425', '300429', '300431', '300433', '300448', '300456', '300479', '300480', '300481', '300482', '300497', '300507', '300657', '300659', '300664', '300665', '300703', '300705', '300710', '301750', '323445', '323447']
    nosy_count = 7.0
    nosy_names = ['terry.reedy', 'ncoghlan', 'vstinner', 'berker.peksag', 'serhiy.storchaka', 'Nir Soffer', 'pablogsal']
    pr_nums = ['3075', '2618', '3120', '3121', '3130', '3134', '3174', '3175']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue30871'
    versions = ['Python 2.7', 'Python 3.6', 'Python 3.7']

    Activity

    1. vstinner commented on Jul 7, 2017

      @vstinner
      MemberAuthor

      While discussing how to dump the readline version in regrtest or test_readline in bpo-29854, I proposed to add a new buildbot step to dump any kinds of debug information. It would avoid to pollute test output with useless information. For example, while the hash implementation is useful for unit tests on the hash function, I dislike always dumping it in the regrtest header.

      The idea would be to get a phpinfo-like report:
      http://php.net/phpinfo

      We can start with an hardcoded list using "try: import xxx except ImportError: pass else: ...", but later we may it more "pluggable" somehow?

      Maybe define a protocol (function with a specific name, maybe a private function?) for each module, add a command which can dump info on a single module, or all modules.

      Maybe start with an hardcoded list of modules, but later discover automatically all stdlib modules?

      I don't expect a regular list of information, but more like a long key-value list.

      Attached pythoninfo.py is an example of such script. It works on Python 2.7-3.7. Example of Python 3.7 output on my Linux PC:
      ---
      cpu_count: 4
      cwd: /home/haypo/prog/GIT/misc/python
      filesystem_encoding: utf-8
      filesystem_errors: surrogateescape
      gdb_version: GNU gdb (GDB) Fedora 7.12.1-48.fc25
      hash algorithm: ('siphash24', '64bit')
      locale_encoding: UTF-8
      platform: Linux-4.11.6-201.fc25.x86_64-x86_64-with-fedora-25-Twenty_Five
      python_implementation: CPython
      readline_library_version: 6.3
      readline_runtime_version: 0x603
      readline_version: 0x603
      sys.byteorder: little
      sys.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)
      sys.maxsize: 9223372036854775807
      sys.version: 3.7.0a0 (heads/testcapi_stack_pointer_master:81dd3fb, Jul 6 2017, 13:10:36) [GCC 6.3.1 20161221 (Red Hat 6.3.1-1)]
      tcl_version: 8.6
      ---

      Later, we may add a JSON output format, to allow to collect informations of all buildbots. For example, check all tested readline versions.

    2. NirSoffer commented on Jul 7, 2017

      NirSoffermannequin
      Mannequin
    3. serhiy-storchaka commented on Jul 7, 2017

      @serhiy-storchaka
      Member

      Something like the CLI of modules site, sysconfig and platform?

      Note that there are two versions: the version with which the interpreter is build, and the version of the dynamic library.

    4. vstinner commented on Aug 11, 2017

      @vstinner
      MemberAuthor

      I wrote #3075 to add "python3 -m test.pythoninfo". I chose to add the script into Lib/test/ to notice users that it's design for Python internal usage, for Python tests.

      I modified scripts running tests on our CI to also run pythoninfo, and then also started to cleanup ("simplify") the regrtest header (remove information rarely useful).

    5. vstinner commented on Aug 11, 2017

      @vstinner
      MemberAuthor

      Nir Soffer: "I like the idea, may be also useful in https://github.com/sosreport/sos/blob/master/sos/plugins/python.py"

      It's hard to guess which kinds of informations are needed. My use case is to debug failing tests on the Python CIs. Other use cases may want other kinds of information.

      For example, my perf module also a "python3 -m perf collect_metadata" which has a similar goal but reads also information about the CPU: CPU configuration, model, temperature, etc. I don't think that these information are useful for Python tests.

      Serhiy Storchaka: "Note that there are two versions: the version with which the interpreter is build, and the version of the dynamic library."

      Sorry, version of what? The readline module has two versions, my proposed test.pythoninfo tool saves both. Depending on the failing test, you need one version or the other, or both.

      The purpose of pythoninfo is to be able to log a long list of informations, without after to care if it is useful or not in general ;-)

    6. berkerpeksag commented on Aug 11, 2017

      @berkerpeksag
      Member

      Two things:

      1. I've just closed PR 2618 as the scope of this issue is broader than my PR.
      2. Could you also add version information of sqlite3?
    7. serhiy-storchaka commented on Aug 13, 2017

      @serhiy-storchaka
      Member

      Sorry, version of what?

      Versions of any external library. Python can be built with headers of one version, but dynamically load the library of other version.

      For example TCL_VERSION and TK_VERSION are static versions (they should be equal in modern Tcl/Tk), and Tcl command "info patchlevel" returns the dynamic version. In the readline module _READLINE_VERSION is header version, _READLINE_RUNTIME_VERSION and _READLINE_LIBRARY_VERSION are runtime versions. In the zlib module ZLIB_VERSION is header version, ZLIB_RUNTIME_VERSION is runtime version.

    8. vstinner commented on Aug 16, 2017

      @vstinner
      MemberAuthor

      Berker: "2. Could you also add version information of sqlite3?"

      Sure, done.

    9. vstinner commented on Aug 17, 2017

      @vstinner
      MemberAuthor

      Serhiy: "For example TCL_VERSION and TK_VERSION are static versions (they should be equal in modern Tcl/Tk), and Tcl command "info patchlevel" returns the dynamic version."

      Ok, I added tkinter.patchlevel info which calls "info patchlevel".

      Serhiy: "In the readline module _READLINE_VERSION is header version, _READLINE_RUNTIME_VERSION and _READLINE_LIBRARY_VERSION are runtime versions."

      The 3 variables are stored.

      Serhiy: "In the zlib module ZLIB_VERSION is header version, ZLIB_RUNTIME_VERSION is runtime version."

      I just added the 2 variables.

    10. vstinner commented on Aug 17, 2017

      @vstinner
      MemberAuthor

      New changeset b907abc by Victor Stinner in branch 'master':
      bpo-30871: Add test.pythoninfo (bpo-3075)
      b907abc

    11. vstinner commented on Aug 17, 2017

      @vstinner
      MemberAuthor

      I created #3120 to add "make pythoninfo" because it's more tricky than what I expected to run "./python -m test.pythoninfo" on buildbots. Depending if Python is built with shared library, depending on the OS (./python, or ./python.exe for macOS?), ... the command is different.

      I plan to backport Lib/test/pythoninfo.py and "make pythoninfo" to Python 2.7 and 3.6 to ease debug on all supported Python branches.

    12. vstinner commented on Aug 17, 2017

      @vstinner
      MemberAuthor

      I plan to backport Lib/test/pythoninfo.py and "make pythoninfo" to Python 2.7 and 3.6 to ease debug on all supported Python branches.

      Oh, but I will first only run pythoninfo on buildbot for the master branch, since I expect surprises depending on the platform :-) Once everything is fine, I will backport the enhancement to other branches.

    13. 10 remaining items

    14. vstinner commented on Aug 21, 2017

      @vstinner
      MemberAuthor

      Ok, pythoninfo is now enabled on Python 3.6 as well.

    15. vstinner commented on Aug 22, 2017

      @vstinner
      MemberAuthor

      New changeset cce1cb9 by Victor Stinner in branch '2.7':
      bpo-30871: Add test.pythoninfo (bpo-3174) (bpo-3175)
      cce1cb9

    16. vstinner commented on Aug 22, 2017

      @vstinner
      MemberAuthor

      I also added pythoninfo to Python 2.7. I made minor adjustements for Python 2.7, like accept (int, long) for integers, remove info only available on Python 3, and add sys.maxint.

    17. vstinner commented on Aug 22, 2017

      @vstinner
      MemberAuthor

      Crap, everything is fine on all CIs... except of a single Windows buildbot using Visual Studio 2010 which doesn't produce the required python.bat:

      http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%20VS9.0%202.7/builds/187/steps/pythoninfo/logs/stdio

    18. vstinner commented on Aug 22, 2017

      @vstinner
      MemberAuthor

      I created bpo-31260: [2.7] Enhance PC/VS9.0/ project to produce python.bat, as PCbuild/

    19. vstinner commented on Aug 22, 2017

      @vstinner
      MemberAuthor

      I modified the buildbot configuration so a pythoninfo failure marks the build as WARNINGS instead of FAILED:
      python/buildmaster-config@3866fac

      But I'm not sure that it works :-/ I forced a build, but the build was marked as FAILED.

    20. vstinner commented on Sep 8, 2017

      @vstinner
      MemberAuthor

      pythoninfo is now available on all buildbots, including Python 2.7 VS9.0 buildbots:
      https://bugs.python.org/issue31260#msg301747

    21. pablogsal commented on Aug 12, 2018

      @pablogsal
      Member

      pythoninfo is failing on several buildbots:

      https://buildbot.python.org/all/#/builders/102/builds/55
      https://buildbot.python.org/all/#/builders/79/builds/237
      https://buildbot.python.org/all/#/builders/112/builds/161
      https://buildbot.python.org/all/#/builders/118/builds/164
      https://buildbot.python.org/all/#/builders/56/builds/105
      https://buildbot.python.org/all/#/builders/18/builds/109

      Example error:

      ./python -m test.pythoninfo
      ERROR: collect_gdb() failed
      Traceback (most recent call last):
        File "/usr/home/buildbot/python/2.7.koobs-freebsd-current.nondebug/build/Lib/test/pythoninfo.py", line 561, in collect_info
          collect_func(info_add)
        File "/usr/home/buildbot/python/2.7.koobs-freebsd-current.nondebug/build/Lib/test/pythoninfo.py", line 300, in collect_gdb
          version = version.splitlines()[0]
      IndexError: list index out of range
    22. pablogsal commented on Aug 12, 2018

      @pablogsal
      Member

      All of these failures seems related to collect_gdb I am going to open a new issue:

      https://bugs.python.org/issue34388

      Please, re-open this one if you think is better to have both open.

    23. transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      3.7 (EOL)end of lifetestsTests in the Lib/test dirtype-featureA feature request or enhancement

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions