[issue29985] make install doesn't seem to support --quiet
Ken Williams added the comment: Thanks Irit - yes, the behavior with 3.9 and 3.10 is the same, and their Makefiles seem to have the same unguarded `echo` statements emitting the output. -- ___ Python tracker <https://bugs.python.org/issue29985> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29985] make install doesn't seem to support --quiet
Ken Williams added the comment:
I poked around a bit more, and it looks like a fair number of the installation
messages are coming from `Lib/distutils/command/build_scripts.py`, which is
using `distutils.log` to show what it's doing:
log.debug("not copying %s (up-to-date)", script)
...
log.info("copying and adjusting %s -> %s", script,
self.build_dir)
...
log.info("changing mode of %s", file)
...
log.info("changing mode of %s from %o to %o",
file, oldmode, newmode)
What I don't see is a way to change the log level, but if that were possible
then I assume that's how `--quiet` could be achieved here.
--
___
Python tracker
<https://bugs.python.org/issue29985>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29985] make install doesn't seem to support --quiet
Ken Williams added the comment: This situation still seems to be the case in 2022. The output of `make altinstall` has thousands of lines like /usr/bin/install -c -m 644 ./Lib/test/__main__.py /usr/local/lib/python3.8/test /usr/bin/install -c -m 644 ./Lib/test/_test_multiprocessing.py /usr/local/lib/python3.8/test /usr/bin/install -c -m 644 ./Lib/test/allsans.pem /usr/local/lib/python3.8/test /usr/bin/install -c -m 644 ./Lib/test/ann_module.py /usr/local/lib/python3.8/test /usr/bin/install -c -m 644 ./Lib/test/ann_module2.py /usr/local/lib/python3.8/test /usr/bin/install -c -m 644 ./Lib/test/ann_module3.py /usr/local/lib/python3.8/test and changing mode of /usr/local/lib/python3.8/lib-dynload/_sysconfigdata__linux_x86_64-linux-gnu.py to 644 changing mode of /usr/local/lib/python3.8/lib-dynload/_sqlite3.cpython-38-x86_64-linux-gnu.so to 755 changing mode of /usr/local/lib/python3.8/lib-dynload/array.cpython-38-x86_64-linux-gnu.so to 755 changing mode of /usr/local/lib/python3.8/lib-dynload/_posixshmem.cpython-38-x86_64-linux-gnu.so to 755 changing mode of /usr/local/lib/python3.8/lib-dynload/_testmultiphase.cpython-38-x86_64-linux-gnu.so to 755 changing mode of /usr/local/lib/python3.8/lib-dynload/_codecs_cn.cpython-38-x86_64-linux-gnu.so to 755 and Compiling '/usr/local/lib/python3.7/test/test_file.py'... Compiling '/usr/local/lib/python3.7/test/test_file_eintr.py'... Compiling '/usr/local/lib/python3.7/test/test_filecmp.py'... Compiling '/usr/local/lib/python3.7/test/test_fileinput.py'... Compiling '/usr/local/lib/python3.7/test/test_fileio.py'... Compiling '/usr/local/lib/python3.7/test/test_finalization.py'... Compiling '/usr/local/lib/python3.7/test/test_float.py'... Compiling '/usr/local/lib/python3.7/test/test_flufl.py'... For me, the problem this causes is that CI build logs get extremely long, so long that my CI build tools won't show the log in the browser anymore and it makes it quite hard to figure out where problems are happening. It looks like the problem is simply that there are lots of `echo` statements in the Makefile.pre.in that could be conditioned on `--quiet`. One small example (in the 'libinstall' target): if test -x $$i; then \ echo $(INSTALL_SCRIPT) $$i $$b; \ $(INSTALL_SCRIPT) $$i $(DESTDIR)$$b; \ else \ echo $(INSTALL_DATA) $$i $$b; \ $(INSTALL_DATA) $$i $(DESTDIR)$$b; \ I don't quite understand how `--quiet` actually gets parsed and recognized by the Makefile, though. -- nosy: +kenahoo versions: +Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue29985> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8538] Add FlagAction to argparse
Ken Williams added the comment:
Thanks, Paul and Eric, for your very quick replies.
You're quite correct, the original question in
https://stackoverflow.com/a/15008806/169947 is indeed hoping for `--foo TRUE`
and `--foo False` etc. to work. Personally I don't like that as much as the
GNU-style `--foo` and `--no-foo` technique, because when you let people type
`TRUE` or `True` or `T` or `1`, etc., it gets a bit confusing about exactly
what is accepted as a true value, what's false, is a zero interpreted as 0 or
"0", whether a failure to parse the value as True or False will be reported as
an error or not, and so on. The user typically can't really know these answers
without reading the actual code, or running it to see what generates an error
(or triggers whatever behavior they're looking for), which is certainly not
ideal.
By contrast, with `--foo` and `--no-foo`, the options are strict and clear.
And supplying an argument will trigger a parse failure.
For @mgilson's proposal, I think the main thing I find unsatisfactory (besides
the fact that it takes 3 lines to define, and I'll have to come back to that SO
answer every time to make sure I get them right...) is that the `--help` output
can't be made clear. With the following specification:
parser.add_argument('--foo', dest='foo', help="Do foo", action='store_true')
parser.add_argument('--no-foo', dest='foo', help="Don't foo",
action='store_false')
parser.set_defaults(foo=True)
we get the following --help text (when using ArgumentDefaultsHelpFormatter):
--foo Do foo (default: True)
--no-fooDon't foo (default: True)
and that last line seems to be a contradiction, or at least very confusing.
The only alternative I see is to turn off ArgumentDefaultsHelpFormatter, but I
think the defaults are generally helpful information for the user.
To fix that --help issue seems to require quite a bit more complicated
registration of arguments, so it's probably not going to happen in most
people's scripts.
I should be clear: I haven't vetted the `argparse_bool.py` proposal in detail
either, so I'm not specifically asking for it to be adopted. Just hoping for a
nice resolution to the `--foo` `--no-foo` issue that codifies best-practices in
a way that makes it trivial to get nice behavior in scripts.
As for documentation - I had poked around in the code a bit and seen the
`register` method, but I thought since it wasn't documented, I'd better not use
it. Is it for public consumption? If so, I'd say it's better documented than
undocumented, even if it provides more info than most people need. My guess is
that enough people are probably using it to make it impossible to eliminate,
which is a good test for whether something should be documented too.
--
___
Python tracker
<https://bugs.python.org/issue8538>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8538] Add FlagAction to argparse
Ken Williams added the comment: @vstinner - I don't think that conclusion is correct, here is a very highly-upvoted answer on SO that indicates a lot of people are still looking for this: https://stackoverflow.com/a/15008806/169947 I myself asked a related (more focused?) question where I was directed here: https://stackoverflow.com/q/53937481/169947 I'm guessing the right thing to do now would be refocus the merge request in a new ticket - is this still the right tracker? -- nosy: +Ken Williams ___ Python tracker <https://bugs.python.org/issue8538> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
