New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add test.pythoninfo #75054
Comments
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: 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: Later, we may add a JSON output format, to allow to collect informations of all buildbots. For example, check all tested readline versions. |
I like the idea, may be also useful in https://github.com/sosreport/sos/blob/master/sos/plugins/python.py |
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. |
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). |
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 ;-) |
Two things:
|
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. |
Berker: "2. Could you also add version information of sqlite3?" Sure, done. |
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. |
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. |
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. |
python -m test.pythoninfo crashes for me on Win10, debug32, but I don't think it is the fault of pythoninfo. See bpo-31288. |
If we end up deciding some of this information might be useful to end users as well, it would be reasonable to extend "python -m sysconfig" to report it, perhaps with the extra imports gated behind a command line option. |
Nick Coghlan: "If we end up deciding some of this information might be useful to end users as well, it would be reasonable to extend "python -m sysconfig" to report it, perhaps with the extra imports gated behind a command line option." Designing such tool is a can of worm. Everybody can have different expectation, different information. IMHO PyPI is a better home for a more general tool. I prefer to keep test.pythoninfo specialized to debug failures on CIs (Travis CI, AppVeyor, buildbots). For test.pythoninfo, I'm mostly interested to get plaintext output right now, and JSON output later, to correlate information. For example, be able to say which readline versions are tested on all buildbots for one Python branch. Moreover, I would like to add test.pythoninfo to Python 2.7 and 3.6. It wouldn't be doable if the tool would be in the stdlib, since these branches don't accept new features ;-) |
I applied Segev Finer's fix for bpo-30121 (commit 4d38517 I added a new pythoninfo step to Unix and Windows buildbots. It seems like everything is fine. I will wait a few days before starting to backport to 3.6, and then 2.7, just in case ;-) Backporting pythoninfo will likely have to wait until bpo-30121 is fixed in Python 3.6 as well. |
Ok, pythoninfo is now enabled on Python 3.6 as well. |
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. |
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: |
I modified the buildbot configuration so a pythoninfo failure marks the build as WARNINGS instead of FAILED: But I'm not sure that it works :-/ I forced a build, but the build was marked as FAILED. |
pythoninfo is now available on all buildbots, including Python 2.7 VS9.0 buildbots: |
pythoninfo is failing on several buildbots: https://buildbot.python.org/all/#/builders/102/builds/55 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 |
All of these failures seems related to https://bugs.python.org/issue34388 Please, re-open this one if you think is better to have both open. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: