[issue26510] [argparse] Add required argument to add_subparsers
Change by Adam Stewart : -- pull_requests: +16178 pull_request: https://github.com/python/cpython/pull/16588 ___ Python tracker <https://bugs.python.org/issue26510> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44253] tkinter searches for tk.tcl in wrong directory
New submission from Adam Stewart : I'm trying to install Python with tkinter support using the Spack package manager. Spack adds the following flags to configure during install: ``` '--with-tcltk-libs=-L/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib -ltcl8.6 -L/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib -ltk8.6' ``` It also sets the following environment variables: ``` TCLLIBPATH='/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib/tcl8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib/tcl8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib64/tcl8.6'; export TCLLIBPATH TCL_LIBRARY=/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib; export TCL_LIBRARY ``` The install seems to correctly pick up tk/tcl and builds correctly. However, when I try to use tkinter, I see the following run-time error: ``` $ python Python 3.8.10 (default, May 27 2021, 13:28:01) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import tkinter >>> tkinter._test() Traceback (most recent call last): File "", line 1, in File "/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/lib/python3.8/tkinter/__init__.py", line 4557, in _test root = Tk() File "/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/lib/python3.8/tkinter/__init__.py", line 2270, in __init__ self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use) _tkinter.TclError: Can't find a usable tk.tcl in the following directories: /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib/tcl8.6/tk8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib/tcl8.6/tk8.6/Resources/Scripts /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib/tcl8.6/tk8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib/tcl8.6/tk8.6/Resources/Scripts /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib64/tcl8.6/tk8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib64/tcl8.6/tk8.6/Resources/Scripts /Users/Adam/spack/opt/spack/darwin-ca talina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib/tk8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib/tk8.6/Resources/Scripts /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/tk8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/tk8.6/Resources/Scripts /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/lib/tk8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/lib/tk8.6/Resources/Scripts /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/lib/tk8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/lib/tk8.6 /Users/Adam/spack/opt/spack/dar win-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/library This probably means that tk wasn't installed properly. ``` It seems that tkinter searches for tk.tcl in `/lib`, but tk.tcl is actually installed in `/lib/tk8.6`. I asked the tk developers, but it looks like `/lib/tk8.6` is indeed the correct installation location: https://core.tcl-lang.org/tk/tktview/447bd3e4abe17452d19a80e6840dcc8a2603fcbc Is there a way to tell tkinter where to find tk.tcl? If not, can we modify the default search path to search in `/lib/tk8.6`? Related to https://github.com/spack/spack/issues/23780 -- components: Tkinter messages: 394584 nosy: ajstewart priority: normal severity: normal status: open title: tkinter searches for
[issue44253] tkinter searches for tk.tcl in wrong directory
Adam Stewart added the comment: Thanks, in that case it sounds like the problem is that Spack installs tcl and tk to separate directories, but since tk depends on tcl and not the other way around, tcl has no way of knowing where tk is installed. I'll see if I can convince the other Spack devs to combine tcl and tk into a single package. -- ___ Python tracker <https://bugs.python.org/issue44253> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44253] tkinter searches for tk.tcl in wrong directory
Adam Stewart added the comment: I think I FINALLY figured out the problem. We were setting `TCLLIBPATH` to `/lib/tk8.6` when it should be `/lib`. With this change, tkinter seems to work for me. Thanks for all of your help! -- ___ Python tracker <https://bugs.python.org/issue44253> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44253] tkinter searches for tk.tcl in wrong directory
Adam Stewart added the comment: And... now it's not working again. Can you clarify exactly how tkinter finds tk/tcl? Does it rely on TCL_LIBRARY or TK_LIBRARY env vars? TCLLIBPATH? If I use all of these env vars, tkinter finds tcl/tk, but commands like: $ python -m tkinter $ python -c 'import tkinter; tkinter._test()' open a window and immediately minimize it. If I try to maximize the window it immediately closes, so something is definitely wrong with my installation. -- ___ Python tracker <https://bugs.python.org/issue44253> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44253] tkinter searches for tk.tcl in wrong directory
Adam Stewart added the comment: Thanks, that does help. Spack uses both `--with-tcltk-includes` and `--with-tcltk-libs`, and actually RPATHs the libraries in place. According to otool, that is all working fine: $ otool -L /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/lib/python3.8/lib-dynload/_tkinter.cpython-38-darwin.so /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/lib/python3.8/lib-dynload/_tkinter.cpython-38-darwin.so: /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib/libtcl8.6.dylib (compatibility version 8.6.0, current version 8.6.11) /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib/libtk8.6.dylib (compatibility version 8.6.0, current version 8.6.11) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) So like you initially thought, the problem isn't that tkinter/_tkinter can't find tcl, it's that tcl can't find tk. I'll talk more with the tcl developers and see how tcl is trying to find tk. Thanks for all of your help! -- ___ Python tracker <https://bugs.python.org/issue44253> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29846] ImportError: No module named _io
New submission from Adam Stewart: I'm trying to build Python 2.7.13 with clang on macOS 10.12.3 with the Spack package manager, but it fails to build the _io module. The exact error message from the build log can be seen here: https://github.com/LLNL/spack/issues/3478#issuecomment-287548431 This only seems to occur for me on macOS; I can't reproduce it on Linux. I checked my environment, but I don't have any Python-related environment variables, nor do I have any variables like DYLD_LIBRARY_PATH set that could cause problems. I'm a developer for the Spack package manager, so any problems that you help me solve will greatly benefit our community. I have attached the build log. Please let me know if there is any more information I can provide you with. -- components: Build files: spack-build.out messages: 289815 nosy: ajstewart priority: normal severity: normal status: open title: ImportError: No module named _io type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file46734/spack-build.out ___ Python tracker <http://bugs.python.org/issue29846> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29846] ImportError: Symbol not found: __PyCodecInfo_GetIncrementalDecoder when building 2.7.x on macOS
Adam Stewart added the comment: > I'm certainly not going to try to deeply analyze a build that inserts *that* > many separate -I and -L options into the compiler calls I believe those were necessary to get the build working. Spack doesn't install anything into /usr/, and without those flags, Python doesn't know where to search for its dependencies. I tried removing them anyway but it didn't help. > My guess is that you will find that the problem goes away if you avoid the > use of '--enable-shared' on the Python configure Just tried this and it does indeed go away! I can try convincing the other developers that this is the best option. > most Python distributions on macOS use --enable-framework rather than > --enable-shared and we seldom test it. I just tried using using `--enable-framework` and `make install` failed. Seeing lots of `ImportError: No module named site` errors. > You should also check that there are no third-party Python 2.7's on PATH > and/or Python 2.7 shared libraries on the dyld library search paths, other > than the Apple-supplied pythons in /usr/bin. This could very well be the cause of the problem. I happen to have both Python 2 and 3 installed with both Homebrew and Anaconda, and all 4 are in my PATH. I don't have any PYTHON or LD/DYLD related env vars though. If you think it's worth testing, I can try removing everything from my PATH except /usr/bin:/bin -- ___ Python tracker <http://bugs.python.org/issue29846> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29846] ImportError: Symbol not found: __PyCodecInfo_GetIncrementalDecoder when building 2.7.x on macOS
Adam Stewart added the comment: I agree, the `--enable-shared` fix is nice, but I would also love to squash this bug. An interesting piece of information: When I provide the full path to the executable (not just relying on the hashed python location), I see: $ /Users/Adam/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/python-2.7.13-tjqn5npfo573q2jw3dumzhzctfd2vvdv/bin/python Python 2.7.10 (default, Jul 30 2016, 19:40:32) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> print sys.version 2.7.10 (default, Jul 30 2016, 19:40:32) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] >>> print sys.path ['', '/Users/Adam/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/python-2.7.13-tjqn5npfo573q2jw3dumzhzctfd2vvdv/lib/python27.zip', '/Users/Adam/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/python-2.7.13-tjqn5npfo573q2jw3dumzhzctfd2vvdv/lib/python2.7', '/Users/Adam/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/python-2.7.13-tjqn5npfo573q2jw3dumzhzctfd2vvdv/lib/python2.7/plat-darwin', '/Users/Adam/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/python-2.7.13-tjqn5npfo573q2jw3dumzhzctfd2vvdv/lib/python2.7/plat-mac', '/Users/Adam/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/python-2.7.13-tjqn5npfo573q2jw3dumzhzctfd2vvdv/lib/python2.7/plat-mac/lib-scriptpackages', '/Users/Adam/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/python-2.7.13-tjqn5npfo573q2jw3dumzhzctfd2vvdv/lib/python2.7/lib-tk', '/Users/Adam/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/python-2.7.13-tjqn5npfo573q2jw3dumzhzctfd2vvdv/lib/python2.7/lib-old', '/Users/A dam/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/python-2.7.13-tjqn5npfo573q2jw3dumzhzctfd2vvdv/lib/python2.7/lib-dynload', '/Users/Adam/.local/lib/python2.7/site-packages', '/Users/Adam/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/python-2.7.13-tjqn5npfo573q2jw3dumzhzctfd2vvdv/lib/python2.7/site-packages'] Note that I am building Python 2.7.13, not 2.7.10. Homebrew installs Python in /usr/local and that version is 2.7.12. My Ananconda installation is in ~/anaconda2 and is 2.7.13. However, the system Python installed at /usr is 2.7.10. Perhaps this is where it is picking up libraries from? Here's some more debug information that could possibly be helpful. I have attached the output of: $ /Users/Adam/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/python-2.7.13-tjqn5npfo573q2jw3dumzhzctfd2vvdv/bin/python -c 'from __future__ import print_function; import sysconfig; vars = sysconfig.get_config_vars(); [print(var, vars[var]) for var in vars]' > ~/python-config-vars.txt Nothing in there looks particularly suspicious to me, but maybe you can find something fishy. I'll try out DYLD_PRINT_LIBRARIES next. -- Added file: http://bugs.python.org/file46743/python-config-vars.txt ___ Python tracker <http://bugs.python.org/issue29846> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29846] ImportError: Symbol not found: __PyCodecInfo_GetIncrementalDecoder when building 2.7.x on macOS
Adam Stewart added the comment: The output of DYLD_PRINT_LIBRARIES is attached as well. -- Added file: http://bugs.python.org/file46744/dyld_print_libraries.txt ___ Python tracker <http://bugs.python.org/issue29846> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29846] ImportError: Symbol not found: __PyCodecInfo_GetIncrementalDecoder when building 2.7.x on macOS
Adam Stewart added the comment: Made a mistake. Please see the new output of DYLD_PRINT_LIBRARIES. This time I actually ran a Python command to see which libraries were loaded. -- Added file: http://bugs.python.org/file46745/dyld_print_libraries.txt ___ Python tracker <http://bugs.python.org/issue29846> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29846] ImportError: Symbol not found: __PyCodecInfo_GetIncrementalDecoder when building 2.7.x on macOS
Adam Stewart added the comment: I also tried building with a Homebrew-installed GCC 6.2.0 but that had the same result. -- ___ Python tracker <http://bugs.python.org/issue29846> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28734] argparse: successive parsing wipes out nargs=? values
New submission from Adam Stewart:
I'm writing a wrapper that optionally accepts a file and reads more options
from that file. The wrapper then needs to pass all of these options and the
file to another program (qsub). Here is a minimal example to reproduce the
behavior I'm seeing:
>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('-a')
>>> parser.add_argument('file', nargs='?')
>>> args = parser.parse_args(['-a', '3', 'myFile'])
>>> print(args)
Namespace(file='myFile', a='3')
>>> parser.parse_args(['-a', '4'], namespace=args)
>>> print(args)
Namespace(file=None, a='4')
The behavior I expect is that the file should remain as 'myFile', but it is
being wiped out. Is there any way to prevent this, or is this actually a bug?
I can recreate this problem in Python 2.7 and 3.5.
--
components: Library (Lib)
messages: 281128
nosy: ajstewart
priority: normal
severity: normal
status: open
title: argparse: successive parsing wipes out nargs=? values
type: behavior
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue28734>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28734] argparse: successive parsing wipes out nargs=? values
Adam Stewart added the comment: Works for me, thanks Wolfgang! -- resolution: -> not a bug status: open -> closed ___ Python tracker <http://bugs.python.org/issue28734> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
