Inspired by https://github.com/miurahr/aqtinstall/issues/696#issuecomment-1651026317. That comment suggested a place to add a log message, but I was unable to log the message there without disregarding the user’s selected log settings, which are not available until the Cli object is built.
When aqtinstall fails to load the py7zr module, it falls back to whatever 7z extraction tool the user has specified in the settings.ini file, without notifying the user. This PR adds the following log message when that happens:
WARNING: The py7zr module failed to load. Falling back to '7z' for .7z extraction.
WARNING: You can use the '--external | -E' flags to select your own extraction tool.
This PR also does a little refactoring of the Cli._set_sevenzip method to improve readability.
Side effect
There was an existing bug here, where the install-qt subcommand (but none of the other commands) would ignore the 7zcmd parameter in the settings.ini file, and use the hardcoded "7z" instead. I'm pretty sure this was a bug; if not I can change it back.
Inspired by https://github.com/miurahr/aqtinstall/issues/696#issuecomment-1651026317. That comment suggested a place to add a log message, but I was unable to log the message there without disregarding the user’s selected log settings, which are not available until the
Cli
object is built.When
aqtinstall
fails to load thepy7zr
module, it falls back to whatever 7z extraction tool the user has specified in thesettings.ini
file, without notifying the user. This PR adds the following log message when that happens:This PR also does a little refactoring of the
Cli._set_sevenzip
method to improve readability.Side effect There was an existing bug here, where the
install-qt
subcommand (but none of the other commands) would ignore the7zcmd
parameter in thesettings.ini
file, and use the hardcoded"7z"
instead. I'm pretty sure this was a bug; if not I can change it back.https://github.com/miurahr/aqtinstall/blob/72da54f4b0156a1bbd0aea09c621992817f963f8/aqt/installer.py#L361-L363